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1 . 0  Introd action 

This  report  documents  a  series  of  studies  that  GSG ,  Inc.  has 
performed  on  the  Fire  Control  System.  The  major  purpose  of 
our  activity  was  to  formulate  a  set  of  recommendations  on 
how  to  best  evolve  the  FCS  in  light  of  its  present  character¬ 
istics  and  the  perceptions  available  of  the  forthcoming 
new  applications  or  enhancements  of  old  applications. 

The  method  we  followed  in  pursuing  the  above  stated  goal 
was  to,  first  of  all,  become  entirely  familiar  with  the 
technical/design  documentation  of  the  FCS  Computer  System. 

We  then  proceeded  to  examine  all  available  (to  us)  studies 
that  characterized  enhanced  applications  for  the  FCS  and 
extrapolated  information  processing  requirements.  The 
latter  we  examined  in  a  very  critical  way  to  determine  the 
soundness  of  the  basic  assumptions  leading  to  figures  for 
throughput,  and  other  information  processing  requirements. 

Having  done  that,  and  considering  the  characteristics  of  the 
architecture  of  the  FCS,  we  determined  the  weak  spots  of  the 
architecture,  in  light  of  the  new  applications,  and  recommended 
a  series  of  moves  that  could  improve  it  to  the  point  of  handling 
the  projected  workload. 
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2 . 0  Management  Summary 

As  stated  in  the  introduction  of  this  report,  the  purpose  of 
the  GSG  study  was  to  understand  the  current  architecture  and 
design  of  the  Fire  Control  System  (FCS) ,  the  list  of  the 
proposed  new  applications  for  this  system,  and  a  series  of 
studies  on  throughput  assessment  and  other  information 
processing  requirement  projections,  to  then  formulate 
directions  for  evolution  of  the  FCS  System. 

In  doing  our  task,  we  were  handicapped  by  a  couple  of  very 
important  elements.  The  first  element  being  a  considerable 
amount  of  program  redirection  that  took  place  while  our 
study  was  proceeding  namely,  at  the  start  of  the  activities 
the  program  was  pegged  around  the  long  term  Trident  II  Program 
This  program  was  subsequently  replaced  by  a  shorter  term 
and  a  more  evolutionary  program,  the  C-4  Upgrade 
(C4U)  Program.  One  important  characteristic  of  the  C4U 
program  is  that  it,  apparently,  has  abandoned  the  premise 
of  the  Trident  II  Program  that  many  of  the  on  board  computers 
could  be  replaced  by  redesigned  machines. 

The  second  element  that  influenced  our  activities  was  that, 
contrary  to  our  normal  methodology,  we  were  largely  left  to 
study  this  program  from  the  written  documentation.  In  fact, 
the  inputs  we  received  from  the  project  team  were  extensive 
amounts  of  technical  documentation  and  a  number  of  formal 
brief ings that  largely  depicted  the  external  characteristics 
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of  the  system.  In  other  words,  there  was  a  dearth  of  informal, 

round  table,  interactive  sessions  with  the  key  desic-ners  of 

the  system.  It  has  been  GSG 1 s  extensive  experience,  that 

reviews  of  this  type  performed  strictly  from  formal  documentation , 

or  formal  briefing  material,  are  handicapped  in  reaching 

the  proper  perception  of  where  the  project  is  at  a  given  point 

in  time.  The  reason  why  this  is  so  is  that  these  projects 

are  usually  always  very  dynamic,  and  situations  change  too 

rapidly  for  the  formal  documentation  to  catch  up.  Further-, 

more,  formal  documentation  very  rarely  has  enough  information 

on  the  rationale  for  choices  made. 

The  above  two  factors,  of  course,  interact  strongly  with  one 
another,  namely,  the  fact  that  the  program  was  undergoing  a 
major  redirection  made  it  even  riskier  to  study  it  strictly 
from  formal  inputs,  or  put  another  way,  would  have  suggested 
the  desirabi  ity  for  extensive  and  informal  communication 
to  supplement  the  information  available  through  the  formal 
documentation . 

The  results  documented  in  this  report  are,  therefore,  to  be 
examined  keeping  in  mind  that  they  are  the  logical  conclusions 
that  derived  from  the  information  available  to  us.  Even  with 
this  kind  of  limitation,  we  believe  that  we  have  achieved 
a  number  of  important  insights  in  the  nature  of  this  program, 
and  that  these  insights  arc  not  necessarily  obsolete  because 
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of  the  unavailability  of  more  recent  information  that  has 
not  been  communicated  to  us.  The  major  conclusions  we  have 
arrived  at  in  this  study  are: 

a.  The  basic  architecture  of  the  FCS  Computer  System 
is  comprised  of  the  architecture  of  the  computer 
itself,  the  TDCC,  and  that  of  its  operating  system, 
the  RTOS .  As  far  as  the  TDCC  is  concerned,  we 

see  that  its  architecture  is  capable  of  handling 
forthcoming  applications  with  the  exception  of 
two  aspects.  One  is  that  the  addressability  of 
the  processor,  especially  at  the  level  of  the 
application  process  has  to  be  expanded,  the 
other  is  that  the  raw  throughput  in  thousands 
of  instructions  per  second  (KIPS)  must  be 
improved  by  approximately  an  order  of  magnitude. 

The  RTOS  is  a  satisfactory  design  that  should 
bo  able  to  handle  all  projected  applications. 

b.  The  program  design,  implementation,  documentation 
approaches  adopted  by  the  FCS  project  are  quite 
satisfactory  and  provide  a  good  base  for  further 
evolution  of  the  software. 

c.  The  sequel  of  throughput  studies  that  was  available 
to  us,  shows  in  an  undeniable  way  that  the  project 
docs  not  have  sufficient  capability  for  architectural 
design.  Architectural  design  being  concerned  with 
the  major  partitioning  decisions  and  major  design 
trade-offs  which  usually  determine  whether  a 
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computing  system  will  be  able  to  do  the  intended 
job.  Key  indicators  that  lead  us  to  this  conclusion 
are  that, in  the  throughput  studies,  a  lot  of  work 
was  expended  in  arriving  at  very  accurate  information 
on  throughput.  For  instance,  instruction  mixes  were 
computed  for  a  number  of  numerical  algorithms.  The 
reason  why  this  very  high  accuracy  is  an  indicator 
of  poor  architectural  design  capability, is  that 
exper icnccdarchitects  know  that  design  quantities, 
at  the  broad  computing  system,  level,  cannot  be  pinned 
down  with  accuracies  much  better  than  plus  or  minus 
30  j.  This  is  not  because  tl.  j  art  of  designing 
computing  systems  is  imperfect  due  to  a 
lack  of  knowledge,  but  rather  because  the  intrinsic 
nature  of  computing  systems  is  that  of  being  queuing 
systems.  Queuing  systems  have  to  be  designed  with 
sufficient  slack  in  their  resources  to  avoid  saturation 
and  system  collapse. 

This  lack  of  computer  system  architectural  sophistication, 
together  with  the  apparent  unfamiliarity  of  the  project  team 
with  the  process  of  independent  reviews,  leads  us  to  believe  that 
it  would  be  very  important  for  programs  of  this  type,  in  view 
of  the  crucial  national  interest  involved,  that  a  practice 
of  periodic  reviews  by  independent  groups  be  adopted. 
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Many  a  development  group  has  discovered  that,  especially  when 
one  is  dealing  with  complex  software  systems,  the  exercise 
of  going  through  an  independent  review  is  most  beneficial  to 
the  design  group  itself.  The  major  reason  is  that  it  forces 
the  design  group  to  articulate  fully  their  assumptions  and 
rationales  so  that  they  can  explain  it  to  a  set  of  competent 
peers.  It  is  the  very  process  of  articulating  and  formulating 
clearly  assumptions  and  rationales  of  choice,  that  forces  a 
better  more  robust  design  which  has  considered  more  exhaustively 
all  available  alternatives. 

Besides  the  above  recommendation  for  adoption  of  a  regular 
policy  of  repeated  design/program  audits,  the  report  gives 
a  number  of  major  recommendations.  We  believe  that  our 
recommendations  on  how  to  extend  or  evolve  the  FCS  System 
will  prove  out  to  be  valid  even  in  light  of  information  we 
may  not  possess  at  this  time.  The  reason  why  we  believe  that 
their  validity  is  independent  of  information  that  we  may  not 
have,  is  that  it  became  very  clear,  during  the  study,  that  the 
FCS  System  is  primarily  throughput  limited  and  addressing 
span  limited.  Our  major  recommendations  are  as  follows: 

Initiate  a  study  to  examine  the  feasibility  of 
reformatting  the  instruction  layout  so  that  room 
cor  a  greater  span  of  application  process  address¬ 
ability  is  found . 
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Expand  the  process  address  space  by  at  least 
two  bits  (i.e.,  64KW->256KW) .  Such  an  expansion 
of  the  process  addressability  would  also  solve 
the  memory  problem,  that  is  it  would  allow 
utilizing  fully  a  one  M  word  memory,  which 
is  within  the  realm  of  physical  possibility 
at  this  time. 

Commission  a  detailed  design  of  a  CPU  which  is 
(software)  upward  compatible  from  the  TDCC  and 
has  approximately  an  order  of  magnitude  greater 
throughput  power. 
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3 . 0  The  FCS  Operating  System 
3 . 1  General 

The  RTOS  is  implemented  for  the  Trident  Digital  Control  Computer 
(TDCC) .  This  computer  features  a  32  bit,  modern,  scientific/ 
process-control ,  word  oriented,  architecture  (See  Sec.  4.0). 

The  only  major  criticism  of  the  architecture,  from  an  operating  system 

point  of  view,  is  that,  it  implements  a  virtual  memory  scheme 

based  on  the  utilization  of  16  base  registers,  each 

spanning  up  to  4K  words  for  a  total  of  64K  words.  The  architecture 

has  two  sets  of  registers,  one  for  the  user  task  and  one  for  the 

euec . 

What  this  implies  is  that  the  virtual  memory  scheme  that  can  be 
implemented  on  this  architecture  limits  the  virtual  address  space 
of  a  particular  '  TOS  process  (tas)')  to  64K  words.  At  the  time  that 
the  system  was  designed,  this  kind  of  address  space  was  more  than 
sufficient.  However,  in  current  designs,  especially  commercial 
ones,  the  tendency  is  to  be  far  less  restrictive  in  the  structure 
of  the  address  or  name  space. 

In  fact  the  tendency  in  commercial  architectures,  which  are  32  bit 
based, is  to  achieve  as  much  as  24  bit  of  addressability  on  a 
per  process  basis,  as  opposed  to  the  16  bits  of  addressibility 
that  the  TDCC  achieves  on  the  per  process  basis.  This  means  that 
a  modern  architecture  can  easily  achieve  as  much  as  4  megawords 
of  addressibility  on  the  per  process  basis.  It  may  rightly  be 
asked  why  one  would  need  such  a  huge  address  space  since  it  is 
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unreasonable  to  expect  that  programs,  especially  applications, 
will  achieve  this  sort  of  size.  However,  the  key  point  of 
achieving  these  very  large  name  spaces  is  for  the  handling  of 
data.  As  ve  shall  discuss  in  Sec.  8.0,  one  of  the  easiest  ways 
to  unblock  the  architecture  for  advanced  applications  would  be 
to  allow  very  large  data  segments  and  this  is  unfortunately 
impossible  with  an  architecture  that  has  only  16  bits  of  addressi- 
biiity. 

Chapter  6  of  Ref.  2  is  a  very  detailed,  proselike,  description 
of  the  monitor  design.  It  is  well  organized  and  furthermore, 
Appendix  A  amplifies  this  very  detailed  documentation  by  giving 
a  set  of  detailed  PDLs  that  document  the  design. 

What  is  missing  in  order  to  make  the  documentation  of  this 
design  absolutely  complete  are  two  fundamental  things. 

The  first  being  a  more  formal  recognition  and  treatment  of  the 
abstract  (virtual)  machines  involved.  What  we  are  referring  to 
is  that  a  section  such  as  5.2  Architecture  Overview,  Ref.  2, 
should  have  been  a  little  more  complete.  In  fact,  in  Sec.  5.2, 
the  architectural  view  is  broken  down  by  indicating  that  the 
system  is  comprised  of  four  basic  abstract  machines.  They  are: 

Basic  processor  hardware 
Monitor 

State  Executive 
Application  tasks 
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(See  Fig.  5.2-1  RTOS  Structure,  Pg.  5-3,  Ref.  2.)  Our  point  is 
that  within, certainly  the  monitor,  and  possibly  the  state  executive, 
it  is  possible  to  isolate  further  layers  of  abstraction,  or 
collections  of  primitives,  which  represent  the  fine  modularity 
of  these  two  portions  of  the  system.  By  the  way,  this  can  also 
be  true  of  specific  application  tasks. 

The  other  missing  factor  in  completing  the  documentation  of  this 
design  is  a  collection  of  functional  diagrams  (HIPO-like) .  To 
illustrate  what  we  mean  by  HIPO-like  diagrams,  we  have  attached 
an  HIPO-like  diagram  for  the  system  resources  processor  function¬ 
ality.  Basically,  these  diagrams  create  a  road  map  of  which 
modules  implement  which  functionality,  and  what  is  the  hierarchical 
relationship  between  the  different  modules. 

The  importance  of  documenting  and  abstracting  structural  infor¬ 
mation,  such  as  the  documentation  of  the  abstract  machines  involved, 
and  the  functional  decomposition  trees,  is  that  it  makes  the 
maintenance  and  further  evolution  of  the  system  a  lot  simpler 
than  conventional  documentation. 

To  illustrate  these  points,  at  least  to  illustrate  the  technique 
oi  an  hierarchical  functional  decomposition  tree,  we  use  the 
example  of  the  monitor  system  resource  processors,  that  is,  the 
monitor  system  resource  management  primitives  which  include  the 
following : 

Digital  Control  Computer  (DCC)  main  memory 

Monitor  controlled  I/O  devices 

Enter  Executive  State  (EES)  service  modules 
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Memory  management  which  comprises  two  major  routines, 
as  follows: 

-  Main  memory  manager:  this  is  the  space  allocator  for 
the  tasks  (processes) . 

Dynamic  manager:  this  is  the  allocator  that  allocate' 
monitor  space  for  control  blocks  and  buffers. 
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3.2  Architecture  of  RTOS 

The  Real  Time  Operating  System  (RTOS)  can  be  configured  for  each 
of  the  system  modes  of  the  Fire  Control  System.  The  system  modes 
correspond  to:  the  test  mode,  the  tactical  mode,  which  corres¬ 

ponds  to  the  actual  operation  of  the  weapons  system,  the  stand-by 
mode,  which  allows  the  updating  of  various  key  data  bases  so  that 
the  weapon  system  is  ready  for  employment,  the  data  entry  mode  which 
allows  in-putting  of  new  information  in  the  data  base  in  preparation 
of  stand-by  and  tactical,  etc. 

This  tailorubility  of  the  OS  to  the  system  mode  is  accomplished 
by  splitting  each  OS  into  two  portions,  one  is  the  monitor  and 
the  other  is  the  executive.  The  monitor  contains  all  the  functions 
■which  are  common  to  all  the  system  modes,  the  executive  contains 
the  functions  which  are  needed  by  a  specific  mode. 

The  concept  of  executive,  in  the  case  of  the  FCS  RTOS,  is  slightly 
different  than  the  classical  concept  of  executive.  The  classical 
concept  of  executive  being,  as  is  well  known,  a  subsystem  that 
implements  the  operator/user  interface  to  the  operating  system. 

RTOS  executives  do  implement  this  user  interface,  however,  they 
also  include  a  portion  of  classical  operating  system  code  which 
is  peculiar  to  a  particular  system  mode.  For  example,  if  a 
particular  device  is  needed  only  in  a  specific  system  mode,  the 
device  driver  and  operating  system  code  related  to  that  device 
would  be  part  of  the  executive  and  not  of  the  monitor. 
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Page  5.5  of  Kef  2  states, "The  monitor  provides  routines  for 
performing  I/O  operations  to  the  following  fire  control  devices: 
MDF,  MTF,  printers,  keyboard,  ICL,  SMCL,  HADL,  DCSS  and  the  TODSS . 
I/O  operations  to  the  other  fire  control  devices  are  the 
responsibility  of  the  state  executives." 

We  presume  that  the  rationale  for  this  division  is  to  guarantee 
that  access  to  certain  fire  control  devices  is  only  possible 
when  a  specific  state  executive  is  in  control.  The  system  has  a 
state  executive  for  each  respective  state,  a  state  being  a 
combination  of  a  system  mode  (of  operation)  together  with  a 
specific  configuration. 

Each  state  executive  is  capable  of  triggering  into  execution 
a  number  c£  application  programs  and  the  linkage  between  the 
application  programs  and  the  specific  state  executive  is  obtained 
by  entering  the  file  descriptors  of  the  application  programs  into 
the  file  directory  of  the  state  executive.  That  is, the  specific 
application  programs  associated  with  a  particular  state  executive 
are  "known  to  it"  in  the  sense  of  the  general  literature  on 
operating  systems. 

Further  tailorability  of  the  system  is  provided  by  the  notion 
of  tailorable  options.  The  tailorabie  option  is  a  system  function 
which  has  to  bo  supp] ied  by  the  state  executive  and  whose 
definition  therefore  is  delegated  to  the  state  executive.  Page  5- 
of  Ref  2  oives  the  list  of  tailorable  options  for  the  state 
executive  as  follows: 
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Local  file  directory  (required) . 

Special  enter  executive  service  (EES) . 

Special  fault  processing. 

Special  I/O  devices  and  associated  interrupt  (DRISS,  DRS 

processing) . 

Special  keyboard  processing. 

Free  and  post  processing  routines. 

Certain  internal  and  external  interrupt  processing. 

Special  processing  for  some  monitor  control  I/O  devices. 

Task/executive  control  common  area  (TECCA) . 

Since  at  any  given  time  there  is  a  single  OS  composed  of  a 
combination  of  a  monitor  plus  a  state  executive,  it  is  possible 
to  override,  in  principle,  the  desiqn  time  functional  split  between 
the  monitor  and  the  state  executive.  In  fact,  the  RTOS  system 
does  provide  a  mechanism  for  such  an  override  and  that  mechanism 
is  called  the  Dynamic  Tailorability  Processors  (See  page  6-48 
of  Ref  2) .  This  mechanism  basically  amounts  to  overriding  the 
Dedicated  Interrupt  Cells  (DIGS)  which  have  been  loaded  up  at 
monitor  initialization  time.  Such  override  would  allow  a  state 
executive  to  substitute  its  own  personalized  fault/interrupt 
processing.  Consequently  the  state  executive  could  take  over  and 
customize  the  processing  for  a  DCC  internal  fault  and  also  to 
customize  the  I/O  operations  to  devices  which  are  normally 
processed  by  the  monitor. 
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As  we  understand  it.  this  override  facility  is  implemented  by 
resorting  to  a  number  of  Executive  Special  Processing  (ESP) 
words  where  each  bit  represents  a  particular  interi apt/fault 
processing  routine  if  the  bit  is  set,  the  corresponding 
routine  will  be  executed.  At  execution  time  when  the 
fault/interrupt  occurs,  the  initial  trap  is  always  t3  the 
original  monitor  dedicated  interrupt  cells.  However, 
examination  of  the  corresponding  ESP  bit  determines  whether  the 
fault/interrupt  is  processed  by  the  state  executive  routine  or 
the  monitor  routine. 

For  obvious  reasons,  any  executive  that  takes  advantage  of  this 
override  capability  must  sativy  two  conditions.  (A)  They  must 
provide,  at  state  executive  initialization  time,  the  necessary 
tra'  sfer  tables,  and  (3)  any  processing  done  by  state  executive 
interrupt/fault  processing  routines  will  be  timed  by  the  monitor. 
Both  conditions  are  obvious,  the  latter  one,  of  course,  is  to 
prevent  a  situation  where  faulty  state  executives  would  cause 
hung  conditions. 

The  architecture  of  the  RTOS  system  seems  to  have  a  basic  DIJKSTRA 
modularity  consisting  of  four  layers,  the  basic  hardware,  the 
monitor,  the  state  executive,  and  the  application  tasks.  It  appears 
that  within  each  one  of  these  elements  there  is  no  further 
DIJKSTRA  modularity. 
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The  RTOS  system  is  a  multi-tasking  system  which  is  capable  of 
full  multi-programming  since  process  scheduling  (See  Sec  3.3) 
is  asynchronously  driven  by  external  interrupts. 

The  above  represent  the  major  architectural  principles  that  can 
be  extracted  from  Ref  2.  Ref  2  also  gives  some  indication  of 
some  potential  problems  in  the  design.  In  particular,  on  page 
6-130,  in  discussing  the  loading  of  a  task  from  disk,  it  indi¬ 
cates  that  the  Attach  primitive  (See  Sec  3.3,  Process  Management) 
ran  -e  called  by  interrupt  routines.  Since  the  Attach  primitive 
can  be  called  by  an  interrupt  routine,  it  must  be  short,  so  this 
forces  deferring  the  disk/tape  load  to  a  later  time  to  be  done 
at  a  processing  level  below  interrupt  processing. 

Shis  is  an  indicator  of  poor  design  since,  for  at  least  the  last 
decade,  operating  systems  have  been  designed  so  that  any  primitives 
connected  with  process  management  and  scheduling  are  implemented 
by  a  mechanism  of  queues,  where  the  interrupt  processing  routines 
only  mark  the  queues.  A  background  scheduler  (processing  at  a 
level  below  moss  interrupt  processing)  will  actually  do  all  of  the 
worx  that  is  involved  m  performing  the  scheduling  primitives. 

The  mechanism  of  limiting  the  interrupt  processing  to  simply 
marking  process  descriptors  on  the  scheduler's  queues,  effectively 
renders  scheduling  completely  asynchronous  from  the  external  in¬ 
terrupts.  (This  in  turn,  removes  all  requirements  for  scheduling 
primitives  to  bo  very,  very  short  and  oven  more  importantly, 
it  removes  the  requirement  for  frequent  and  often  extended 
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disarming  of  the  interrupt  system.)  The  latter  is  a  crude 
way  of  proiectina  extended  critical  sections. 

One  other  comment  with  regard  to  tne  architecture  of  the 
Rf OS  is  that,  as  presently  described  by  the  RTOS  monitor  design 
disclosure  document,  the  architecture  is  captured  by  a  significant 
volume  of  prose.  Furthermore  the  prose  is  not  very  well  organized 
from  a  point  of  view  of  an  architectural  description,  since  for 
instance,  points  that  have  to  do  with  the  actual  gross  structure 
of  the  system  are  scattered  over  chapter  five  and  six,  points 
regarding  process  management  are  scattered  again  over  many,  many 
sections,  etc.  However,  the  greatest  single  deficiency  is  not  to 
have  resorted  to  some  of  the  standard  techniques  of  documenting 
the  functional  decomposition  of  the  architecture.  What  we  are 
referring  to  is  the  use  of  cither  Visual  Table  of  Contents 
diagrams  or  HIPO  charts  to  indicate  how  the  different  architectural 
modules  are  decomposed  into  functions  and  subfunctions. 

V?e  believe  that  this  is  an  unfortunate  deficiency  since  the  design, 
as  we  comment  elsewhere  is  quite  good,  the  degree  of  prose/ 
documentation  describing  the  design  is  more  than  adequate,  and 
then  finally,  the  fact  that  the  project  adopted  the  very  rigorous 
discipline  of  documenting  the  entire  programming  design  by  the 
use  of  the  program  design  language  (PDL)  with  the  PDL  listings 
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being  made  an  integral  part  of  the  design  documentation.  Having 
done  all  this  extensive  effort,  a  small  amount  of  additional 
effort  would  have  made  the  overall  design  disclosure  document 
much  more  effective,  especially  from  the  point  of  view  of  new 
personnel  trying  to  delve  into  a  design  unfamiliar  to  them. 
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3.3  Process  Management. 

In  this  section,  we  will  present  the  information  given  in  Ref.  #2 
with  regard  to  task  scheduling  in  the  perspective  of  current 
understanding  of  the  theory  of  operating  systems. 

rTOS  appears  to  be  an  operating  system  based  on  the  notion  of 
processes.  In  fact  RTOS  tasks  share  most  of  the  attributes  of  the 
abstract  notion  of  processes.  The  RTOS  processes  (tasks)  can  be 
divided  into  three  broad  categories;  those  which  are  in  the  dormant 
state,  those  which  are  in  the  connected  state,  and  finally,  those 
which  are  in  the  active  state. 

Kef.  2  pg  6-102  defines  dormant,  connected,  and  active  tasks  as 
follows : 

Dormant  has  no  exclusive  resources.  In  particular  it  has 
no  control  point. 

Connected  has  exclusive  resources  and  at  least  a  control 
point.  The  system  admits  32  control  points  with  ranks 
1  through  31. 

Active.  A  task  is  active  if  it  has  an  activation  record, 
main  memory,  and  i.s  in  some  stage  of  execution. 

In  view  of  the  fact  that  the  control  point  table  appears  to  be 
the  main  entry  table  for  all  scheduling  decisions  we  would  read 
this  definition  of  state  in  a  slightly  different  way.  Namely,  it 
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seems  to  us  that  the  most  important  distinction  is  whether  or  not 
the  task  or  process  is  known  to  the  system.  As  it  is  customary  in 
the  literature  on  operating  systems,  an  entity  is  considered  known 
to  the  system  if  the  control  table  corresponding  to  that  class  of 
entities  has  a  specific  entry  relating  to  the  entity.  From  that 
point  of  view, we  see  that  tasks  which  are  dormant  are  not  known 
to  the  system  since  the  control  point  table  docs  not  have  a 
corresponding  entry  for  them,  while  tasks  which  are  either  connected 
or  active  are  known  to  the  system. 

Another  way  to  put  it  is  that  the  transitions  from  the  dormant  to 
the  connected  state  and  vice  versa,  correspond  to  the  macro  level 
of  scheduling  of  tasks,  or  in  other  words,  introducing  tasks  for 
consideration  by  the  system.  The  transitions  between  the  connected 
and  the  active  states,  and  their  inverse,  correspond  to  processes 
being  entered  or  -xi  led  from  the  lower  level  scheduling  process. 

This  lower  levei  scheduling,  as  it  is  well  known,  is  the  true  process 
scheduling  and  basically  is  the  activity  of  resource  contention  for 
processes.  In  other  words,  once  a  process  enters  the  active  state, 
it  is  competing  with  all  other  processes  for  resources  such  as 
memory,  CPU,  channels,  and  peripherals. 

The  active  state  in  turn  is  divided  into  three  sub-states:  enabled, 
executing,  and  disabled.  Once  again,  referring  to  standard  operating 
system  literatures,  they  correspond  respectively  to  runnable, 
running,  and  blocked. 
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In  the  enabled  state  a  process  has  just  come  out  of  a  wait,  therefore, 
it  satisfied  the  wait  and  it  is  contending  for  the  CPU  so  to  be 
able  to  run.  In  the  executing  state  the  process  has  all  the  resources 
it  needs  in  order  to  execute.  In  the  disabled  state  the  process 
has  been  blocked  by  either  requesting  an  I/O  operation,  and  therefore 
be  forced  to  wait  for  its  completion, or  by  executing  the  primitive 
that  puts  it  to  sleep. 

Page  6-107  of  Ref.  2  describes  the  scheduling  primitives  that 

the  RTOS  monitor  provides  to  higher  level  software  such  as  task 
executives.  The  primitives  are  as  follows: 

Attach  primitive  (ref  2  does  not  refer  to  primitives 
but  rather  to  functions).  This  primitive  effectuates  the 
transition  from  the  dormant  state  to  the  connected  state. 

In  other  words,  the  Attach  primitive  presents  a  process 
to  the  system  and  makes  it  known  to  the  system. 

Detach  primitive.  This  primitive  does  the  opposite  operation 
of  the  Attach,  namely,  it  deletes  a  process  from  the  list 
of  known  processes  freeing  up  the  control  point  that  was 
assigned  to  the  process.  Thus  this  primitive  effectuates 
the  transition  from  the  connected  state  to  the  dormant  state. 

Schedule  primitive.  This  primitive  effectuates  the 
transition  from  the  connected  state  to  the  active  state 
and  in  particular  to  the  enabled  sub-state.  In  other  words, 
this  primitive  poses  a  process  for  lower  level  scheduling  , 
that  is,  for  actual  resource  confection. 
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-  Exit  primitive.  This  primitive  executes  the  transition  from 
the  active  state,  in  particular  from  the  executing  sub-state 
to  the  connected  state.  In  other  words,  this  primitive 
causes  the  process  to  abandon  resource  contention  with 
other  processes  and  transfer  to  a  condition  where  it  is 
only  known  to  the  system  but  not  competing  for  resources. 

Purge  primitive.  This  primitive  is  executed  whenever  an 
abnormal  termination  of  a  process  occurs.  In  other 
words,  it  is  similar  to  exit,  except  that  exit  is  executed 
for  normal  termination  of  a  process  while  purge  is  executed 
when  a  process  causes  a  fault  or  other  offending  condition. 

This  primitive  effectuates  the  transition  from  the  active 
scate  to  the  connected  state.  In  other  words,  the  purge 
primitive  can  be  executed  out  of  any  of  the  sub-states  of 
the  active  state  leading  to  the  connected  state. 

Waite  primitive.  This  primitive  effectuates  the  transition 
from  the  executing  sub-state  to  the  disabled  sub-state  of 
the  active  state.  Thus  this  primitive  causes  a  running 
processes  to  suspend  execution  and  become  blocked. 

Continue  primitive.  This  primitive  effectuates  the  transition 
between  the  disabled  sub-state  and  the  enabled  sub-state  of 
the  active  state.  That  is,  this  primitive  causes  a  blocked 
process  to  become  unblocked  or  runnable  and  therefore  to 
queue  up  for  processor  scheduling. 


S.  G\,  Inc. 


-26- 


The  three  groups  of  primitives.  Attach  and  Detach;  Schedule  purge, 
and  Exit;  and  Continue  and  Waite,  cover  all  of  the  transitions  of 
the  state  diagram  which  includes  the  states:  Dormant,  Connected,  Active 
(Enable,  Disable,  Executing)  except  the  transition  between  the  enabled 
and  the  executing  sub-state  of  the  active  state.  This  transition 
is  effectuated  by  an  interrupt  processing  routine,  namely  the  clock 
interrupt. 

The  RTOS  monitor  has  a  clock  interrupt  processing  routine 

which  processes  a  two  hundred  millisecond  clock  interrupt.  This  clock 

interrupt  will  take  care  of: 

I/O  time  out. 

Printing  out  monitor  messages. 

Hardware  alarm  processing. 

Read  navigation  and  time  of  day  information. 

Timing  out  of  processes  which  have  been  put  to  sleep  by  a 

Waite  primitive. 

Together  with  the  periodical  clock  interrupt  the  system  has  to  process 
also  the  interrupts  that  come  from  I/O  operations  and  unsolicited 
interrupts  that  arrive  from  operator  actions.  The  interrupt  processing 
routines  for  all  of  these  interrupts  are  capable  of  looking  at  the 
set  of  enabled  tasks/processes  and  picking  the  next  one  for  execution. 
In  other  words,  the  transition  from  enabled  to  executing  occurs 
upon  an  interrupt  processing  routine  finding  out  that  the  current 
executing  task  (CET)  can  no  longer  run  and  by  looking  at  whether 
there  is  any  task  that  is  ready  to  run  and  giving  to  it  the  processor. 
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Page  5-15  of  reference  2  indicates  that  the  scheduling  primitives 
described  above  arc  the  sole  interface  for  scheduling  functions  on 
the  part  of  user  software.  In  other  words,  the  task  executives 
can  set  up  their  own  scheduling  policy  by  executing  the  scheduling 
primitives  described  above. 

Another  way  to  explain  all  this  is  to  consider  that  the  transitions 
between  the  various  states,  dormant,  connected,  enabled,  etc.,  can 
be  performed  in  two  ways.  One  is  by  a  higher  level  software  executing 
a  scheduling  primitive  to  obtain  the  services  of  the  monitor  for 
scheduling  purposes,  the  other  is  for  the  interrupt  processing  level 
of  the  monitor  to  actually  effectuate  some  of  these  transitions. 

For  example,  the  transition  between  disabled  and  enabled  can  either 
be  effectuated  by  executing  a  Continue  primitive  which  is  a  call 
on  the  monitor,  or  it  can  be  executed  by  an  I/O  interrupt  processing 
routine  recognizing  that  an  I/O  operation  has  been  completed  and 
that  a  process  that  was  blocked  for  that  I/O  operation  now  is  ready 
to  proceed  and  therefore  can  be  put  in  the  enabled  state. 

Page  6-107  of  Ref.  2  further  confirms  the  above  understanding 

as  follows  "The  scheduler  provides  the  nucleus  around  which 
executive  dependent  scheduling  algorithms  are  built". 

Page  6-105  of  Ref.  2  describes  the  activation  record  for  a 

task  as  inclusive  of  434  words  of  main  memory.  This  memory  being 
dedicated  to  storing  two  stacks  and  one  fixed  size  storage  area. 

The  first  stack  is  136  words  and  is  the  executive  stack  whose  name 
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is  EX$STK .  The  second  stack  includes  256  words  and  it  is  used  by 
both  the  monitor  and  state  executive  and  it  is  called  with  the  name 
DATA$STK . 

The  first  stack  appears  to  store  linkage  information  The  second 
stack  is  stated  to  store  callers  context  information  only. 

The  fixed  storage  area  of  42  words  is  used  to  store  the  task 
environment  information,  i.e.,  this  appears  to  be  a  process  control 
block. 

To  complete  the  subject  of  process  management,  the  remaining  topic, 
that  needs  to  be  treated,  is  the  issue  of  process  scheduling  priority. 
This  issue  is  treated  by  RTOS  by  utilizing  the  notion  of  process 
rank.  The  system  is  designed  to  have  32  distinct  ranks  or  priorities 
the  number  32  being  chosen  because  it  corresponds  to  the  size  of  the 
computer  word  so  that  a  particular  bit  in  the  word  can  be  utilized 
to  indicate  the  presence  or  absence  of  a  task  of  a  given  rank.  This 
very  fundamental  architectural  decision  is  in  turn  predicated  of  the 
idea  that  this  allows  very  fast  scheduling  algorithms  to  be  implemented. 
In  fact,  logical  operations  on  machine  words  is  all  that  is  required  to 
implement  such  algorithms.  Page  B-2  of  the  Ref.  2  clearly  states 

that  this  indeed  is  the  mechanism  used  at  the  base  of  RTOS  process 
scheduling.  In  fact,  it  says,  "There  are  presently  defined  in  the 
extended  computer,  32  possible  control  points  per  machine  state. 

Each  is  equivalent  to  a  task  rank  within  the  MTS.  This  rank  shows 
the  relationship  between  tasks.  Equated  to  priority  as  it  does  with 
interrupts.  It  is  also  a  quick  and  efficient  way  of  identifying  a 
task  and  its  corresponding  monitor  control  information  in  ^he  MTS". 
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Page  6-109  of  Ref.  2  indicates  that  the  rank  from  0  to  31 

corresponds  to  32  priority  levels  each  allowing  a  single  task,  that 
is,  rank  is  used  as  an  index  in  the  CPCON  table  of  control  points. 

Obviously  for  this  mechanism  of  rapid  access  to  the  control  point 
table  to  work,  there  has  to  be  a  single  known  process  associated 
with  each  control  point.  It  follows  therefore,  that  this  design 
allows  only  32  connected  processes  or  tasks  since  the  maximum  amount 
of  control  points  is  32  and  since  each  control  point  must  have  a 
single  known  process,  that  is  connected  process.  This  mechanism 
docs  not  put  any  particular  restriction  on  the  number  of  dormant 
processes.  Confirmation  of  the  uniqueness  of  the  connected  tasks 
to  a  control  point  corns,  from  page  6-129,  of  Ref.  2,  in  the 
discussion  of  the  \ttach  primitive  states:  "If  some  other  task  is 
connected  at  a  control  point,  then  a  control  point  conflict  error 
exists."  In  other  words,  in  the  process  of  making  a  process  or 
cask  known  to  the  system  (Attach)  ,  if  the  control  point  or,  what  is 
the  same  the  priority, that  has  been  chosen  for  the  new  process  is 
already  assigned  to  some  other  process,  the  Attach  primitive  will 
give  an  error  condition. 

Two  important  algorithms  in  the  monitor  are  the  TAC  (Task  Activation 
Controller)  and  the  TTC  (Task  Termination  Controller) .  The 
process  termination  routine  TTC  is  called  in  the  same 
way  as  the  process  activation  routine  TAC.  One  key  difference  is 
that  the  TTC  runs  at  priority  (rank)  0  while  TAC  runs  at  the  same 
priority  as  that  of  the  process  being  activated. 
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TTC  lunnim;  w •  t  h  {um.c  i  :  y  i !.. ' .1  :'< .-s  that  the  roleasa  of  system 

resources  occ..lj  wi  *  1.  «  he  .11  ;he  •*  •>riority. 

Page  6-11  j  01  L.itos ,  " Since  only  members  of  the  ’"TS 

can  do  terminate'.!,  it  i  s  sui'i  jcicnc  to  represent  .  ne  tasks  (to  be 
terminated)  list  as  a  word  i  '  which  each  bit  set  indicates  a  rank 
of  .■>  task  to  be  terminated.  ”  .  rh:  particular  sentence  conclusively 
oroves : 


1.  At  each  priority  level  there  can  bo  a  simple  known  process. 

2.  Ilardwar.  dependency  (o2  bit  word)  at  the  vary  heart  of  the 
process  scheduler. 


Furthermore,  page  6-121  of  ho f .  2  indicates  that  all  scheduling 

queues  are  implemented  as  single  word  bit  mask  algorithms. 

On  page  6-114  of  Ref.  2,  a  very  detailed  verbal  description 

of  the  process  termination  algorithm  is  given.  At  this  time,  as 
well  as  many  othar  places  in  tha  monitor  document,  the  use  of  a 
few  flow  charts  could  have  saved  an  enormous  amount  of  prose  and 
resulted  in  greater  clarity. 

In  conclusion,  the  process  management  scheme  proposed  by  RTOS  is 
a  fairly  classical  interrupt  driven  process  management  scheme 

and  our  only  serious  reservation  about  it  is  the  architectural 
decision  to  use  the  word  dependent  quantity  of  32  bits  as 
the  basic  underpinning  for  process  priority  handling.  We  understand 
of  course  the  rationale  for  it,  which  is  that  once  32  priority 
levels  are  chosen,  one  can  associate  each  of  them  with  the  particula 
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bit  position  in  the  computer  word  and  that,  in  turn,  would  allow 
many  compare  and  selection  operations  to  be  based  of  fast  logical 
operations  on  computer  words .  On  the  other  hand  this  kind  of 
architectural  decision  invariably  winds  up  being  a  poor  one  in  the 
long  term  because  it  imposes  some  very  hard  limits  on  the  expandability 
of  the  architecture.  In  other  words,  what  we  are  saying  is  that 
probably  good  chunks  of  the  monitor  code  have  this  built  in  constant 
of  32  and  are  based,  worse  yet,  on  the  assumption  of  the 
word  and  its  bit  array  as  the  underlying  structure  to  keep  track 
of  priority.  This  has  two  bad  consequences,  one  is  that  if, 

in  the  further  evolution  of  the  system,  one  were  to  need  more  than 
32  connected  (known)  processes  at  any  given  time  in  the  system,  it 
would  be  very  difficult,  with  this  kind  of  system,  to  expand  it  to 
accomodate  the  new  requirements.  The  other  bad  effect  is  that, 
were  the  system  to  be  re-implemented  onto  a  machine  which  has  a 
•different  basic  architecture,  for  instance  a  machine  that  were  not 
word  oriented,  at  least  not  32  bit  word  oriented,  then  the  system 
as  such  could  not  be  transferred  or  ported  to  the  new  machine 
architecture.  We  fully  understand  that  the  RTOS  monitor  is  not 

ve’-y  portable  because  it  was  implemented  in  assembly  language  anyway, 
so  this  argument  could  be  accused  of  being  specious. 

The  key  point,  in  all  this,  is  that  one  of  the  fundamental  advances 
of  computer  sciences  is  that  the  details  of  lower  layers  data 
structures  should  not  be  visible  at  higher  layers  of  the  system. 

This  advance  is  very  fundamental  because  it  is  the  key  to  the 
portability  of  the  higher  levels  with  respect  to  the  changes  in 
the  lower  layers.  Or  what  is  the  same,  stated  in  the  converse 
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fashion,  it  is  the  key  to  the  freedom  of  redesign  and  implementation 
of  tne  lower  layers  without  unduly  impacting  the  higher 
layers . 


This  fundamental  principle  of  computer  sciences  is  deeply  violated 
by  the  notion  of  using  a  data  structure  of  uhe  hardware  machine  as 
the  basic  underpinning  of  the  architecture  of  the  process 
management  layer  of  the  operating  system.  In  fact,  what  one 
is  doing  is  using  the  computer  word,  which  is  the  data 
structure  of  the  lowest  layer  of  the  system  (the  hardware  machine) , 
with  all  its  gory  details  of  number  bits  and  sequence  of  bits, 
mapping  priority  into  least  significant,  most  significant,  that  sort 
of  thing,  and  making  all  this  extremely  visible  to  a  layer  of  the 
operating  (the  process  management),  which  is  not  even  the  lowest 
layer  of  the  software,  in  fact  the  lowest  layer  being  interrupt 
processing.  So  there  is  no  question  that  this  is  a  poor  decision 
which  will  have,  in  future,  significantly  costly  consequences. 

Furthermore,  wo  believe  that  the  rationale  behind  this  particular 
choice  was  eminent ly  wrong  since,  even  though  we  fully  realize  that 
the  preoccupation  of  the  designers  was  to  achieve  a  true  real  time 
operating  eastern,  experience  with  the  design  of  many  operating 
systems  shows  that  it  is  rarely  the  actual  execution  of  CPU 
instructions,  executing  scheduling  algorithms,  that  gets  in  the  way 
of  satisfying  operating  system  performance  requirements  or  even 
real  time  scheduling  deadlines.  What  usually  gets  in  the  way  are 
waits  for  secondary  resources  such  as  copies  of  information  from 
disk,  access  to  channels,  obtaining  enough  main  memory,  etc. 
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Further  proof  of  the  validity  of  what  we  are  saying  is  the  very 
modern  design  of  the  VAX  VMS  operating  system  which  is  designed 
to  handle,  in  a  quite  satisfactory  way,  real  time  processes  and 
absolutely  shyed  away  from  implementing  schedulers  in  any  kind 
of  word  mask  oriented  fashion.  In  fact,  this  very  successful 
operating  system  implements  scheduler  queues  in  the  classical  way 
that  most  operating  systems  implement  them,  namely  as  treaded 
lists  v.  f  process  descriptors. 
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3.1  Memory  Management . 

The  Memory  Management  of  tne  UTOS  system  is  a  "real  memory  management 
system  for  automatically  handling  overlays  of  application  tasks. 

The  system  is  articulated  around  three  primitives  which  are: 

Acquire. 

Release. 

Ovload. 

The  require  primitive  is  used  by  several  classes  of  users  to 
request,  from  the  Memory  Allocator,  that  a  block  of  a  given  size  be 
allocated  in  real  memory  for  their  use.  The  classes  of  users  that 
can  use  the  Acquire  primitive  are: 

Monitor. 

State  executives. 

Any  of  a  possible  set  of  32  privileged  application  tasks. 

After  customary  checks  and  controls,  the  Acquire  primitive  obtains 
services  from  the  Main  Memory  Allocator  which  in  turn  returns,  if 
available,  a  block  of  memory  that  satisfies  the  specification  in 
the  request.  An  important  point  is  that  the  Acquire  primitive  returns 
the  absolute  address  of  the  memory  block  that  has  just  been 
allocated. 

The  Release  primitive  performs  a  converse  action,  namely  it  can  be 
called  by  the  same  users  described  under  the  Acquire  primitive  and 
it  releases  memory  that  these  users  may  have  acquired  previously 
through  an  Acquire  primitive.  The  Release  primitive  is  capable  of 
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either  releasing  an  individual  block  or  all  the  memory  that  belongs 
to  that  particular  user. 

The  two  above  primitives  are  basically  the  fundamental  mechanism 
for  allocation  of  memory  and  the  memory  that  is  being  allocated  is 
primarily  the  user  area.  Ref.  2  on  page  5-4,  fig.  5.2-2  shows  the 
overall  memory  map  of  the  RTOS  system.  This  map  shows  that  the 
physical  memory  is  divided  into  three  portions,  the  area  common  to 
the  monitor  and  the  executive,  the  area  reserved  to  the  monitor,  and 
an  user  area.  The  user  area  in  turn  is  subdivided  into  an  area 
dedicated  to  the  state  executive  and  an  area  that  is  reserved  for 
the  user  tasks.  Although  the  monitor  will  use  these  allocation 
mechanisms  for  allocating  its  own  code,  the  primary  use  is  really 
in  allocating  the  user  area,  that  is,  the  state  executive  plus 
application  task  areas. 

Further  insight  on  how  specifically  the  memory  management  operates 
is  given  of  page  6-34  of  the  ref.  2,  fig.  6-9. 3. 2  which  gives  the 
memory  layout  for  a  typical  task.  This  memory  map  indicates  that 
the  portion  of  the  user  area  which  is  dedicated  to  the  application 
task  is  further  subdivided  into  a  non-overlayable  area  and  an 
ovorlayable  area.  The  non-overlayable  area,  in  turn,  is  divided 
into  three  portions,  the  first  being  the  task  activation  record, 
the  second  being  the  task  control  tables,  the  third  being  the 
overlay  zero  or,  that  isy  the  root  overlay.  The  overlayable  area 
includes  all  of  the  other  overlays. 
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Page  6-82  of  ref.  2,  fig.  6. 9. 3-1  gives  a  typical  overlay  structure 
for  an  application  task.  Basically,  the  point  of  the  figure  is 
to  show  that  a  task  can  build  an  arbitrary  tree  structure  of 
overlays.  That  s,  each  overlay  in  the  structure  can  in  turn  have 
any  number  of  sons  overlays  which  in  turn  can  have  sons  overlays 
and  so  on  and  so  rorth. 

The  Ovload  primitive  is  a  primitive  that  fetches  overlays  and 
locates  them  or  loads  them  into  main  memory.  The  mechanism 
hrough  which  allocation  conflicts  are  completely  elimated  so  that 
the  Ovload  primitive  can  operate  with  no  fear  of  resource  contention 
is  that  when  the  task  is  scheduled,  the  scheduler  requests  a 
memory  block  large  enough  to  include  all  of  the  task  control  tables, 
including  the  activation  record,  and  the  longest  overlay  path.  The 
reason  why  this  allocation  strategy  is  pursued  is  that  the  way  the 
Ovload  primitive  works  is  that  it  will  not  load  the  N  th  overlay  in 
a  given  path  of  an  overlay  tree  unless  the  (N-l)th  one  overlay  is 
already  memory  resident.  Consequently,  to  guarantee  absolute  avoidance 
of  memory  contention,  one  must  allocate  a  block  of  main  memory  that 
is  large  enough  to  contain  all  of  the  overlay  down  the  path  of  the 
tree  which  will  require  the  most  memory. 

This  memory  management  scheme  is  extremely  simple  and  rudimentary, 
and  while  having  all  the  benefits  of  simplicity,  it  has  the  funda¬ 
mental  disadvantage  that  it  could  result  in  significant  inefficiency 
in  the  utilization  of  main  memory.  However  with  the  current  trends 
towards  packaging  and  cost  of  memory,  memory  efficiency  should  not 
be  a  major  concern  of  a  program  of  this  type. 
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This  scheme  is  adequate  as  long  as  the  number  of  application  tasks 
competing  for  main  memory  allocation  is  limited.  If  the  system 
were  to  evolve  in  a  direction  where  a  large  number  of  truly 
con-current  tasks  are  competing  for  main  memory  allocation,  it 
would  be  highly  desirable  to  evolve  the  memory  management  towards 
a  more  truly  virtual  memory  orientation. 
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3.5  Device  and  I/O  Management. 

The  RTOS  design  does  not  make  a  very  marked  difference  between 

the  I/O  management  and  file  management.  Basically  the  monitor 

< 

provides  the  following  I/O  primitives: 


Locate. 

MDF/MTF  Read/write. 

DIO. 

Print. 

PI PRINT. 

ICL  Send/"’.eceive . 

Keyboard/display. 

In  this  section  we  will  discuss  most  of  these  primitives  except  the 
Locate  and  Road/Write  primitives  which  shall  be  discussed  in 
Sec.  3.5.  Pile  Management. 

The  DIO  primitive  (devi.ee  I/O)  basically  allows  an  application 
task  to  set  up  a  channel  program  (DCWs) .  The  point  being  that, 
obviously, the  control  of  the  DCWs  has  to  be  in  the  hands  of  the 
monitor  for  system  integrity.  However  through  the  DIO  interface 
the  application  task  has  functionally  the  same  kind  of  control 
as  a  monitor  program  could  have  on  a  channel  program. 
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The  DIO  interface  is  available  for  the  following  devices: 

MDF . 

System  printer. 

Computer  printer. 

MTF . 

The  DIO  interface,  by  utilizing  the  Device  Control  Block (DCB) 
concept  attains  a  degree  of  device  independency  with  respect  to 
the  application  tasks. 

The  print  primitive  provides  low  level  printer  I/O  for  both 
the  system  printer  (HADL  alarms,  FCS  alarms,  test  results)  and 
the  computer  printer  which  is  used  for  normal  printing  usage. 

The  keyboard/display  primitive  appears  to  provide  traditional 
I/O  support  for  a  keyboard  display  complex. 

The  ICL  Send/Receive  primitives  appear  to  be  specialized  I/O 
services  to  allow  two  basic  kinds  of  high  speed  transfers.  The 
first  transfer  is  swapping  arbitrary  amounts  of  memory  content 
from  the  user  task  space  to  the  global  disk  space  and  vice 
versa.  The  other  specialized  transfer  is  the  copying  of  a  maximum 
of  ten  words  of  ICL  buffer  space  out  of  the  Monitor  Executive 
Common  Communication  Area  (MECCA) in  or  out  of  the  user  task  space. 

In  balance  the  I/O  services  provided  by  the  monitor  are  pretty 
standard  low  level  I/O  interfaces  to  those  devices  which  are  managed 
by  the  monitor  so  that  task  executives  or  application  tasks  can  gain 
access  to  the  full  low  level  functionality  of  the  device  without 
compromising  the  integrity  of  the  resource  which  remains  controlled 
by  the  monitor. 
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3.6  File  Management. 

The  file  system  of  the  RTOS  is  based  on  the  file  directory  which 
appears  to  be  the  collection  of  the  File  Control  Blocks  (FCB) . 
nage  B-4  of  Ref.  2  indicates  that  there  are  two  directories, 

a  global  file  directory  and  a  local  file  directory.  The  local 
file  directory  is  specific  to  each  system  state.  At  any  given 
time  the  file  directory  is  really  a  combination  of  the  local  state 
directory  with  the  global  directory. 

A  rootnote  on  this  page  indicates  that  some  system  programs  or  FCBs 
are  in  Moncom  and  that  is,  they  are  not  really  normal  FCBs,  but 
special  ones.  The  special  FCBs  are  for  the  Task  Termination 
Controller  (TTC)  and  the  Hardware  Alarm  Detection  Logic  (HADL)  which 
need  these  quasi  FCBs  for  scheduling  them  as  processes. 

Normally  these  kinds  of  solutions  of  having  pre-defined  objects 
which  are  handled  in  special  ways  are  indicators  that  the 
architecture  of  i;he  system  has  not  been  thought 

out  correctly  for  limiting  conditions.  In  other  words,  we  consider 
the  existence  of  these  special  FCBs  and  the  special  mechanisms  for 
handling  them  as  an  indicator  of  potential  problems  with  the 
monitor. 

From  the  memory  maps  of  the  monitor  and  the  monitor  plus  the  executive 
given  on  page  13  of  appendix  D  of  Ref.  2,  it  appears  that  the 

global  directory  and  the  local  directory  are  resident,  respectively,  in 
monitor  and  executive  memory.  This  type  of  design  would  be  justified 
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if  only  few  files  are  involved  and  certainly  would  have  the 
advantage  of  cutting  down  of  iisk  accesses.  However, as  all  these 
kinds  of  choices, it  would  get  in  the  way  of  future  expansion  of  the 
system. 

The  file  directory  capability  present  in  RTOS 

introduces  the  notion  of  logical  file  names,  so  that  it  makes 
application  programs  invariant  under  the  reconfiguration  of  the 
disk,  in  other  words,  the  introduction  of  a  rudimentary  file 
directory  capability  prevents  having  to  recompile  the  application 
programs  every  time  the  files  are  moved  around  on  the  disk. 

In  the  case  of  RTOS  it  is  not  quite  possible  to  make  a  very  clear 
distinction  between  file  management  and  I/O  or  device  management. 
However,  we  will  discuss  in  this  section  only  those  primitives 
which  can  be  more  normally  equated  with  file  management.  The  monitor 
includes  the  following  I/O  primitives: 

Locate. 

MDF/MTF  Read/write. 

DIO 

Print. 

PIPRINT 

ICL  Send/receive. 

Keyboard/display 

In  this  section  we  will  discuss  the  Locate,  and  the  Read/Write 
primitives,  since  they  are  the  only  ones  that  more  properly  could 
be  considered  related  to  file  management. 
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The  Locate  primitive  searches  the  file  directory  utilizing  a  logical 
name  and  returns  the  address  of  the  FCB  corresponding  to  that 
file  name,  if  it  is  available  at  all. 

The  Read/Write  primitives  treat  the  MTF  as  an  extension  of  the  MDF, 
in  fact  the  same  file  directory  is  utilized  for  both  devices.  All 
operations  are  file  name  oriented.  Essentially  what  the  ReadAJrite 
primitives  offer  is  a  sub-set  of  the  natural  Read/Write  operations 
of  the  respective  devices. 

In  other  words,  in  thin  file  system  there  is  no  record  abstraction 
One  could  say,  in  terms  of  modern  nomenclature,  that  it  implements 
byte  stream  files.  The  operations  are  very  low  level  and 

the  only  real  abstraction  that  is  involved  is  introduction  of  a 
file  name  orientation  to  the  operation  so  that  recompilation  of 
application  programs  can  be  avoided  in  restructuring  mass  storage. 

Furthermore,  the  Locate  does  not  "open"  a  file  since  the  Read/Write 
primitives  also  search  for  the  FCB  corresponding  to  a  particular 
file  name  on  the  file  directory. 

In  balance,  this  file  management  system  is  extremely  primitive  and 
not  very  different  from  a  standard  low  level  I/O  control  system. 

Just  about  the  only  thing  it  introduces  is  the  notion  of  symbolic 
file  name  or  a  logical  file  name. 
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3 . 7  Reliability ,  Availability,  Maintenance 

Sec.  5.6  Fault  and  Recovery  Processing  (Pg.  5.27  of  Ref.  2) 
illustrates  the  basic  philosophy  for  fault  detection  and 
recovery  for  the  RTOS  System.  The  basic  philosophy  can  be 
summarized  by  saying  that  the  design  stresses  the  importance 
of  detecting  very  early  and  in  a  very  comprehensive  way,  all 
the  faults  that  occur,  however,  the  monitor  does  not  attempt 
any  recovery  actio  s  whatsoever  and  recovery  is  considered  the 
responsibility  of  either  the  operator  or  specific  task  executives. 

The  basic  design  philosophy  in  this  critical  area  of  the  system 
is  best  captured  by  quoting  verbatim  from  tho  reference  mentioned 
above. 

"F or  all  fault  interrupts  which  have  not  been  tailored  by  the 
executive,  the  B?  will  be  halted,  thus  preventing  the  completion 
of  a  critical  sequence  with  the  existence  of  a  fault.  Software 
detected  faults  may  or  may  not  halt  the  BP,  depending  upon  the 
seriousness  oi  the  offense.  It  is  important  to  note  here  that 
fault  processing  is  a  tailorable  feature,  permitting  executives 
to  by-pass  the  standard  monitor  fault  processing  if  they  so 
desiro . 

Elements  of  the  philosophy  consist  of  the  following: 

a.  The  OS  design  includes  modules  which  vigorously  attempt 
to  detect  faults  as  early  in  the  sequence  as  possible. 
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b*  To  facilitate  fault  analysis  at  GEOS  and  NSWC/DL,  sufficient 
information  about  the  environment  of  the  fault  will 
be  gathered  in  a  central  memory  area,  such  that  the  fault 
may  be  easily  traced  to  its  source.  This  information, 
called  the  fault  signature,  is  not  intended  for  use  by 
the  fire  control  operator,  but  instead  should  be  captured 
on  a  tape  cartridge  via  the  DATALOG  feature  of  the 
maintenance  panel  whenever  a  computer  stoppage  occurs, 
and  returned  to  NSWC/DL  or  GEOS  for  analysis  purposes. 

c.  As  a  standard  philosophy,  automatic  recording  of  the 
fault  signature  data  on  a  mass  memory  device  (MDF  or  MTF ) 
will  not  be  performed. 

d.  Retries  are  attempted  on  certain  I/O  devices.  The  number, N, 
of  retries  is  a  device  dependent  characteristic  and  may 

be  input  at  system  generation  time.  The  device  is 
considered  failed  only  after  N  successive  unsuccessful 

retries . 

e.  After  a  fault  has  been  processed,  the  OS  does  not  initiate 
any  automatic  recovery  sequence,  but  instead  permits  the 
operator  to  initiate  any  recovery  deemed  necessary, 
probably  as  written  in  the  standard  operating  procedures 
(SOPS)  . 
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f .  Requests  for  monitor  services  are  checked  for  validity. 
Invalid  requests  v/ill  result  in  the  requestor  being 
purged.  Valid  I/O  "equests  which  generate  device 
failures  will  result  in  the  requestor  being  informed 
(via  posting)  of  this  condition. 

g.  All  CPU  fault  interrupts  are  catastrophic.  If  such 
faults  occur,  the  monitor  will  (after  collecting  the 
fault  signature  in  a  central  memory  area)  halt  all 
system  activity.  In  this  case,  the  operator  will  be 
forced  to  perform  a  bootstrap  operation. 

Realizing  that  executives  are  a  part  of  the  OS,  and  furthermore, 
that  *rauit  processing  is  a  tailorable  feature,  executives  may 
substitute  special  executive  fault  processing  routines  and  thus 
by-pass  the  standard  OS  fault  processing  philosophy.  In  such 
cases,  executives  may  provide  for  recording  fault  signatures  on 
mass  memory,  initiating  an  automatic  recovery  sequence,  etc. 

This  is  the  only  case  where  the  standard  OS  philosophy  may  be 
circumvented. " 

Pg.  6-137  of  Ref.  2  and  many  other  places  before  and  after,  indicate 
that  any  scheduler,  I/O,  and  other  OS  primitives,  upon  discovering 
an  error  condition,  will  call  a  routine  named  BAD$FPT.  It  is 
evident,  therefore,  that  BAD$FPT  is  a  common  error  handling 
routine  for  the  monitor. 
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Putting  this  element  of  the  design  together  with  the  philosophy 
stated  above,  one  has  to  Cuiicluuo  that  BAD$FPT  is  the  agent 
that  signals  to  the  caller  of  the  primitive,  which  would  have 
better  intelligence  on  how  to  handle  the  err  r  condition,  the 
existence  of  an  error/abnormal  condition. 

We  interpret  the  above  design  philosophy  as  being  motivated 
by  a  desire  to  guarantee  that  the  system  : s  always  in  positive 
control  condition.  That  is,  our  interpretation  is  that  specific 
executives  are  allowed  to  lake  up  the  automatic  fault  handling 
and  recovery  since  specific  executives  may  be  carrying  out  non- 
critical  portions  of  the  mission  while,  of  course,  other 
executives,  primarily  those  of  the  tactical  mode,  cannot  be  so 
allowed.  If  the  automatic  error  handling  and  recovery  wore  to 
be  imbedded  into  the  monitor,  then  all  executives  and  therefore, 
all  modes  of  the  PCS  system  would  proceed  with  automatic  recovery. 
By  architecturally  assigning  the  task  of  recovery  to  the  executive 
one  can  guarantee  that  certain  kinds  of  recovery  situations 
are  handled  strictly  through  human  intervention. 

It  so  happens  that  this  particular  philosophy,  which  obviously  was 
dictated  by  the  special  mission  of  the  PCS,  dovetails  with 
current  thinking  about  how  error  handling  should  be  architected. 

In  fact,  modern  thinking  about  the  architecture  of  operating 
systems  is  increasi  igly  affirming  the  point  that  the  inner 
layers  of  the  operating  system  (in  this  case,  the  monitor)  have 
only  the  function  of  defecting  errors  and  signalling  to  higher 
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callers  the  condition.  It  is  the  higher  level  callers,  which 
have  knowledge  of  the  context,  which  are  allowed  to  do 
automatic  recovery  or  reconfiguration  or  whatever. 
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4 . 0  The  TDCC  Architecture 

The  Trident  Digital  Control  Computer  (TDCC)  architecture 
represents  a  conventional  approach  to  providing  general 
purpose  computing  power  to  the  Trident  II  Fire  Control 
System  (PCS).  Whereas  it  possesses  some  architectural 
attributes  which  facilitate  real  time  processing,  it 
has  not  been  specifically  tailored  to  FCS  functions. 

'he  MK  98  MOD  0  is  defined  to  include  the  Central 
Processin j  Unit  (CPU),  its  main  memory,  a  communications 
controller  and  the  multiplexor  portion  of  the  Data  Communi¬ 
cations  Processor  (DC?) . 

in  general ,  it  is  a  sequential,  register  oriented,  thirty- 
two  bit  word  machine.  It  possesses  multiple  interrupt 
levers  (forty-eight  in  all),  dual  state  (executive  and 
task)  instructions  and  registers,  instruction  look  ahead 
and  some  degree  of  micro  programming.  Of  these  character¬ 
istics  the  only  unusual  item  is  the  duplication  of  both 
-eneral  purpose  registers  (16  per  group)  and  the  base/ 
protection  registers  (32  per  group) .  These  registers  are 
separated  into  two  groups:  the  task  and  executive.  This 
distinction  was  purportedly,  made  in  order  to  simplify 
processing  by  allowing  access  without  cross-state  register 
contention.  There  are  some  registers  which  permit  either 
state  access  and  thus  facilitate  executive-task  communication . 
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Conventional  addressing  schemas  are  utilized  through  a 
combination  of  real  and  base  register  offset  addressing. 

All  addressing  is  on  word  boundaries  with  partial  word 
offsec  capabilities  {quarter  word,  half  word,  f"ll  word, 
double  word,  variable  length) .  Maximum  real  addrcssibility 
is  256K  words  {due  to  the  18  bit  address  field) .  There  is 
no  distinction  between  instruction  and  data  specific  addressing 
An  operand  only  stack  capability  is  also  present.  Multiple 
stacks  arc  permitted  and  may  be  placed  at  any  point  in  memory. 
The  scack  technique  implemented  is  a  simple  one  which,  although 
it  has  all  necessary  stack  instructions  (PUSH,  PUSH  DOUBLE,  POP 
POP  Double,  LOAD  from  Stack,  Store  to  Stack,  Load  Double  from 
Siack,  Store  Double  o  Stack  and  modify  Stack  Description), 
makes  no  attempt  to  speed  execution  by  placing  top  stack 
elements  in  cache,  registers  or  other  faster  than  normal 
access  memory. 

Aiso  present  in  the  addressing  schema  arc  multiple  and  indirect 
addressing  and  indexed  (offset)  with  base  register  addressing. 
Virtual  memory  capabilities  were  also  described,  (64  K  words 
segme  .ted  into  16,  4  K  word  sections),  however,  their  actual 
method  of  use,  or  benefits  were  not  clearly  discussed. 

Areas  of  interest  for  possible  future  enhancements  include 
re-implementation  of  MK98  with  newer  technology,  enhanced  stack 
capabi li ties ,  more  optimized  addressing  schemas,  and  use  of 
specialized  processors.  We  would  like  to  briefly  discuss 
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some  ideas  with  regards  to  methods  by  which  the  MK98  FCS  could 
be  enhanced  without  catastrophic  effects  on  existing  software 
systems.  The  basic  premise  is  that  although  the  MK93  is  an 
architectural Jy  adequate  CPU,  some  areas  could  be  optimized 
without  signif icantly  altering  the  FCS  as  a  whole. 

Processor  re-implementation  is  probably  the  simplest  option 
available.  The  '1K93  has  been  benchmarked  at  between  129  and 
225  KIP's  depending  on  the  actual  instruction  mix  being 
executed.  It  is  probable  that,  with  new  technology  alone 
these  performance  factors  could  be  at  least  doubled  and  very 
likely  tripled.  These  factors  could  be  further  enhanced  by 
some  of forts  to  optimize  instruction  operator  codes  with  regards 
to  frequency  of  occurrence  and  machine  representation.  However , 
this  complicates  implementation  by  requiring  recompilation  or 
possibly  translation  of  current  software. 

Stack  operations  could  also  be  enhanced  by  implementing  top 
level  stack  positions  in  high  speed  cache  memory.  Current 
memory  access  times  were  stated  to  be  540  nsecs  (word  or  byte, 
memory  cycle  time  or  real  access  time,  read  or  write?),  with 
current  technology  this  time  can  certainly  be  decreased  to  less 
than  200  nsecs  or  better,  with  such  an  approach.  This  option 
requires  more  effort  to  implement  so  its  desirability  depends 
directly  on  degree  of  stack  usage. 
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The  need  to  increase  machine  memory  capabilities  was  also 
mentioned  in  several  documents  which  GSG  received.  Through¬ 
out  the  discussion  of  memory  expansion  was  the  thread  of 
minimum  effects  on  operational  software.  An  option  mentioned 
but  never  really  discussed  was  the  distinction  between 
instruction  and  data  address  spaces  (I  and  D  space) .  This 
distinction  was  never  really  discussed  in  the  documents 
received  but  nevertheless  represents  a  very  practical 
method  by  which  machine  addressing  may  be  optimized  to 
either  maintain  current  addressing  limits  with  decreased 
address  field  size,  or  to  maintain  address  field  size  and 
increase  total  memory  which  may  be  accessed. 

Finally,  the  use  of  specialized  processors  is  another  way 
by  which  the  MK  98  may  be  relieved  of  some  rather  significant, 
and  in  some  cc  >es  very  specialized,  processing  requirements. 

These  options  were  mentioned  to  some  degree  in  papers  discussing 
the  "missilized"  versus  the  "phased"  approach  to  the  IAP .  The 
use  of  specialized  processors  makes  very  good  sense,  particularly 
in  the  areas  of  array  processing,  for  applications  such  as  the 
FCS.  However,  the  degree  of  effectiveness  is  directly  affected 
by  the  method  of  implementation.  A  key  example  is  the  method 
of  data  communication.  In  other  words,  does  the  specialized 
processor  have  Direct  Memory  Access  (DMA)  priviledges  or  does 
it  have  +:o  process  data  through  an  intermediary  communications 
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controller?  Such  considerations  are  ard  must  be  address^ 
if  the  final  results  are  to  be  the  best  possible. 
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5 . 0  Implementation  Tools 

5 . 1  Characteristics  of  the  Trident  Higher  Level  Language  (THLL) 

The  user's  guide  provided  by  NSWC  provides  substantial  detail 
concerning  the  TIILL  implementation  currently  utilized  by  SP-23 
applications.  THLL  itself  is  a  block  structured,  procedure 
oriented  language.  Data  typing  is  extensive  and  once  defined 
is  not  runtime  changeable  within  a  specific  procedure.  The 
THLL  compiler  is  a  four  pass  implementation  which  produces 
directly  executable  MK98  and  MK83  FCS-DCC  (Fire  Control  System  - 
Digital  Control  Computer)  direct  code. 

THLL  possesses  very  flexible  execution  control  facilities 
(such  as  GOTO,  SWITCH  and  CASE  statements)  however,  NSWC 
internal  policy  directs  that  structured  programming  techniques 
be  used  wherever  possible.  Language  facilities  necessary  for 
mathematical  FCS  solutions  are  provided  in  abundance  through 
both  the  standard  arithmetic  operators  and  extensive  built-in 
functions  including  specific  macros  to  facilitate  Cartesian 
and  Polar  coordinate  geometries.  THLL  provides  the  capability 
to  define  multiple  LIFO  operand  stacks  of  differing  types  along 
with  the  minimum  instruction  set  necessary  for  their  use. 
Although  only  minimal  character  manipulation  facilities  are 
provided  this  is  not  deemed  to  represent  a  deficiency  for 
fire  control  applications. 
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As  mentioned,  data  typing  of  variables  is  mandatory  for  the 
THLL  compiler.  Six  discrete  data  types  are  available  for 
procedure  use  (half,  integer,  double,  real,  pointer,  and 
alpha) .  A  seventh  type  (no  type)  is  used  for  valueless 
items  such  as  statements.  Once  a  variable  has  been  typed, 
its  type  may  not  be  runtime  modified  within  a  procedure. 

Strong  data  typing  protocols  are  established  for  the  results 
returned  by  all  operators  (assignment  type  conversion  tables 
are  found  in  Appendix  B  of  the  THLL  user's  guide) .  Procedure 
typing  is  also  used  to  control  the  types  of  values  returned 
by  called  procedures.  Untyped  procedures  indicate  no  value 
is  to  be  returned.  Although  the  data  typing  is  not  so  strong 
as  that  of  PASCAL,  we  believe  it  is  more  than  sufficient  for 
SP-23  purposes. 

Strict  operator  precedence  is  enforced  with  addressing 
operators  having  the  highest  precedence  immediately  followed 
by  binary  operators.  Normal  mathematic, logic ,  and  assignment 
operator  precedences  follow  these.  As  in  other  HOL  compilers, 
normal  order  of  execution  is  left  to  right,  in  accordance  with 
specific  operator  precedences.  This  order  may  be  modified 
through  the  conventional  use  of  parenthesis. 

THLL  provides  visibility  of  RTOS  services  through  a  series 
of  "service  procedures".  Capabilities  provided  include: 

Attach  a  task  to  the  multitask  set  (MTS) ;  Schedule  a  task 
for  execution;  Purge  a  task;  Detach  (remove)  a  task  from  the 
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MTS ;  Exit  (terminate)  program  execution;  various  program  wait 
options;  continue  execution  (priviledged  instructions);  multiple 
interrupt  control  options;  overlay  controls;  multiple  procedure 
control  options;  system  error  handler,  and  data  block  summation. 
Ke  detected  no  deficiencies  in  the  RTOS  options  available  for 
applications  task  use. 

In  summary  THI,L  appears  to  be  competent  for  the  specific  task 
it  was  designed  to  satisfy.  It  satisfies  the  basic  EOL 
definition  of  one  source  code  instruction  yielding  more  than 
one  object  code  instruction.  It  has  many  of  the  language 
characteristics  and  conventions  of  ALGOL  while  also  permitting 
users  to  directly  manipulate  memory  locations  at  the  lowest 
level  (i.e.  bit  manipulation  of  a  specific  real  or  virtual 
location) .  Instruction  repertoire  necessary  for  efficient 
output  formatting  and  character  string  manipulations  are 
deficient  in  a  general  sense,  however,  they  appear  satisfactory 
for  the  task  at  hand.  Flexible  program  sequence  controls  are 
available  and  although  their  use  is  restricted  by  internal 
convention,  embody  the  most  desirable  features  of  other 
languages  such  as  FORTRAN  and  ALGOL. 

The  only  area  of  concern  is  the  direct  ability  of  programmers 
to  access  real  machine  addresses  and  bit  manipulate  data. 

Such  abilities  while  they  enable  more  efficient  memory  use- 
will  tend  to  increase  the  complexity,  development  and  main¬ 
tenance  costs  of  FCS  software.  If  the  bit  manipulation  and 
real  address  capabilities  are  extensively  used  the  cost  savings 
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realized  by  requiring  structured  programming  techniques  may 
be  significantly  offset.  Such  usage  will  tend  to  decrease 
program  maintainability  somewhat  as  well  as  increasing  the 
time  necessary  to  train  new  programming  personnel. 
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5 . 2  THLL  Translatability  to  PTSCAL/ADA 

This  section  addresses  the  translatability  of  THLL  based 
software  into  other  HOL  languages,  in  this  case  PASCAL  and 
ADA.  Compiler  availability,  although  critical  in  real  terms, 
is  not  considered  at  this  point.  Rather  we  are  simply 
discussing  the  similarities  and  potential  difficulties 
to  be  faced  if  and  when  a  decision  is  made  to  move  away 
from  THLL. 

While,  today,  such  a  move  within  SP-23  is  not  likely,  other 
organizations,  some  of  which  are  Navy,  have  found  that  internal 
support  of  system, s  support  software  such  as  communications 
systems  and  compilers  has  proven  too  costly  to  sustain.  It 
is  true  that  such  internal  support  yields  specialized 
capabilities,  but  there  is  a  definite  price  to  be  paid.  This 
price  is  realized  in  terms  of  organizational  resources  dedicated 
to  development  and  maintenance  of  existing  capabilities,  develop 
new  capabilities  and  most  importantly  to  train  new  personnel. 

An  additional,  but  not  always  obvious  side  effect,  is  the 
inability  of  internally  supported  organizations  to  rapidly 
capitalize  on  new  technology.  This  inability  will  often 
result  from  available  personnel  assets  being  consumed  in  day 
to  day  evolutions  -  thereby  making  them  unavailable  to 
sufficiently  analyze  new  technologies . 


For  all  of  the  reasons  mentioned  above  GSG  feels  that  it  is 
appropriate  to  discuss,  at  a  general  level,  the  feasibility 
of  TULL  translation.  This  discussion  concentrates  on  such 
areas  as  the  basic  context  and  logical  structure  of  the 
languages  (is  it  block  structured),  available  data  types, 
basic  operators,  available  macros  or  functions  (e.g.  trigono¬ 
metric  functions),  data  precision,  degree  of  programmer 
separation  from  the  physical  machine,  she  ability  to  interact 
with  the  operatin'!  system  ore.  All  of  these  areas  must  be 
addressed  if  one  is  to  reasonably  assess  the  feasibility  of 
a  ianguaae  to  language  translation. 

With  regards  to  the  first  of  these  points  -  the  basic  context 

and  logical  structures  of  the  three  languages  -  the  common 

ALGOL  ancestry  proves  beneficial.  All  three  follow  the  same 

structural  concepts,  consistency  of  data  typing  within  i 

procedures,  clear  beginning  and  ending  of  blocks,  recursive 

ability,  locality  of  data  values  etc.  Thus,  an  attempt  to 

convert  TULL  to  ADA  or  PASCAL  is  not  likely  to  encounter 

significant  difficulties  in  these  areas. 

Although  the  locality  of  data  type  definition  is  consistent 
among  all  three  languages,  the  actual  availability  of  data 
typos  is  not.  THLL ,  for  example,  possesses  seven  types  - 
half,  integer,  double,  real,  pointer,  alpha,  and  no  type. 

Standard  PASCAL  on  the  other  hand  has  only  four  actual  types  - 
real,  integer,  boolean  and  character,  a  fifth  type  (user  defined) 
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is  available  but  only  allows  type  definition  and  assignment 
of  allowable  values.  ADA  is  more  nearly  in  line  with  THLL 
by  allowing  character,  boolean,  integer,  real  (with  variable 
precision  -  there  is  no  double  precision  per  se) ,  array,  records 
and  access  type'..  Thus,  with  regards  to  data  type  availability, 
ADA  is  easily  compatible,  PASCAL  (in  its  common  form)  may 
cause  difficulties  with  regards  to  unavailability  of  double  - 
precision  and  the  inability  to  specify  digits  of  precision. 
Another  deficiency  of  PASCAL,  when  compared  to  THLL  is  the 
lack  of  a  pointer  capability.  ADA  possesses  an  "address- 
specif ication"  feature  which  provides  a  capability  similar 
to  the  pointer  of  THLL. 

Built-in  function  availability  for  PASCAL  includes  the 
standard  sine,  cos,  cosine,  square,  square  root,  absolute 
value,  arc  can,  exponential,  natural  logs  and  others.  ADA 
prefers  to  rely  on  the  availability  of  specialized  libraries 
or  programmer  defined  programs  for  these  functions.  Therefore, 
for  an  ADA  implementation  FCS  required  library  functions  such 
as  cine,  cosine,  arc tan  etc.  would  have  to  be  provided  in  some 
manner.  They  would  not  appear  as  normally  supplied  ADA 
intrinsics . 

Programmer  separation  from  the  physical  machine  refers  to 
the  ability  of  a  programmer  to  address  specific  real  machine 
addresses  and  to  "bit  twidlc" .  Both  THLL  and  ADA  support  these 
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facilities  at  about  the  same  level,  common  PASCAL  does  not 
directly  support  either  capability.  A  conversion  from  TULL  to 
?iDA  is  feasible  from  this  point-of-view,  however,  some  recoding 
would  bo  necessary  to  reflect  type  specification  differences. 
This  statement  does  not,  however,  address  the  desirability  of 
allowing  programmers  to  gain  physical  machine  access.  In 
general,  it  may  be  said  that  such  accessibility  is  undesirable 
from  a  system  maintenance  point-of-view,  unless  a  strong 
performance  case  can  be  made  for  essential  functions. 

A  final  area  cf  significant  concern  is  the  one  of  language 
interaction  with  the  operating  system.  Both  TIILL  and  ADA 
provide  such  a  capability  through  interrupt  and  exception 
handling  definition  features,  PASCAL  does  not  normally  provide 
such  a  capability. 

For  an  operating  environment  such  as  encountered  by  SP-23 
applications,  this  is  viewed  as  the  most  significant,  and 
in  this  case  a  fatal  deficiency.  Such  flexibility  is 
mandatory,  we  i_eel,  for  a  real  time,  stand  alone  operation 
such  as  the  FCS  em ironment . 

In  summary,  although  all  three  languages  -  THLL,  ADA  and 
PASCAL  share  a  common  ancestry  (ALGOL) ,  they  differ  in 
their  current  implementation.  THLL  maintained  all  the 
capabilities  necessary  for  its  target  applications  and 
while  not  ignoring  other  functionalities  such  as  character 
or  string  manipulation,  did  not  provide  the  same  degree  of 
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f legibility .  ADA  on  the  other  hand  is  a  more  general  purpose 
language  which  provides  all  the  flexibilities  of  THLL  plus 
additional  enhancements  which  would  provide  little  benefit 
to  SP-23  applications.  Significantly  absent  from  ADA.  however, 
are  the  mathematic  and  trigonometric  built-in  functions  of 
TiiLL  and  PASCAL.  These  must  be  provided  externally  from  ADA 
i tsolf . 

If  a  translation  from  THLL  becomes  necessary,  then  in  GSG ' s 
opinion,  it  is  feasible  with  some  normal  conversion  difficulties, 
to  translate  TIILL  source  to  ADA  source.  It  would  not,  however, 
be  feasible  to  perform  such  a  transition  from  THLL  to  PASCAL 
due  to  data  type  and  precision,  physical  machine  access  and 
operating  system  interface  inconsistencies. 

One  final  note  is  chat  these  comparisons  are  based  on  preliminary 
ADA  specifications  as  published  in  June,  1979.  ADA  specifications 
are  subject  to  review  and  redefinition  until  such  time  as  the 
final  reports  are  issued. 
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6 . 0  Soft Lwa re_  Dove lopme n t  Mo t hodo logy 
6.1  Software  Development  Life  Cycles 

The  backbone  of  the  software  development  methodology  of  the 
DCS  project  is  a  life  cycle  management  system  broken  up  into 
discrete  phases  with  corresponding  baselines.  In  other  words, 
the  backbone  of  the  methodology  reflects  state-of-the-art 
concepts  on  the  management  of  software  projects.  The  specific 
prase  method  utilized  by  this  projecl  has  the  following  phases: 

System  Definition:  During  this  phase,  functional  and 
performance  requirements  are  generated  and  documented. 

System  Design:  During  this  phase  the  actual  design 
specifications  are  generated. 

System  Implementation:  During  this  phase  the  software 
is  actually  programmed  and  a  detailed  design  results 
in  a  number  of  design  documents. 

System  Test:  During  this  phase  the  actual  debugging 
of  the  system  takes  place.  Documentation  produced 
during  this  phase  consists  of  test  plans  and  procedures. 

System  Deployment:  This  is  the  phase  in  which  the  system 
is  installed  in  the  fleet.  Documentation  produced 
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The  life  cycle  management  scheme  used  by  the  FCS  anticipates 
that  the  V&V  activities  are  performed  throughout  the  last 
three  phases  above. 

The  V&V  activities,  in  themselves,  have  a  flexible  approach  to 
recycling  information  relating  to  problems  discovered  in  the 
software.  They  are  biased  on  classical,  well  proven  approaches, 
such  as  controlled  release  of  patches  for  short-term  fixes, 
to  be  followed  by  long-term  design  changes  or  implementation 
changes,  which  are  brought  about  by  the  system  developers, 
and  are  authorized  and  approved  by  a  Change  Control  Board. 

An  interesting  concept  that  is  utilized  in  this  program,  to 
guarantee  the  accuracy  of  computational  results,  is  the  notion 
of  having  a  specific  critical  algorithm  implemented  twice  by 
two  distinct  set  of  people  coding  it  for  two  distinct  computers 
ant;  in  distinct  languages.  In  one  case  the  algorithm  is  coded 
for  the  CDC  G700  and  in  the  other  case,  it  is  coded  for  the 
■'’ire  Control  Computer,  that  is  the  TDCC .  The  two  versions  of 
the  algorithms  generate  results  which  are  compared  via  a 
compare  program.  If  the  results  are  equal  then  this  is  a  very 
strong  validation  of  the  functionality  of  the  algorithm.  Clearly, 
extreme  measures,  such  as  these,  are  required  because  of  the 
obvious  criticality  of  the  mission  of  this  weapon  system. 

The  methodology  also  envisions  a  system  for  generating  trouble 
and  failure  reports  (TFRs)  and  a  process  to  collect  the  TFRs 
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from  the  fleet  with  a  centralized  processing  of  the  TFRs  at 
Corona  del  Mar.  The  central  point  in  Corona  del  Mar,  after 
analysis  and  synthesis,  feeds  back  the  important  TFRs  to  the 
developers  so  that  the  problem  can  be  diagnosed  and  a 
correction  be  generated. 

In  summary,  we  can  say  that  the  life  cycle,  baseline,  and 
VfcV  processes  that  are  adopted  by  this  program  are  comparable 
to  some  of  the  best  in  the  computer  industry,  with  an  actual 
added  emphasis  on  V&V  activities  because  of  the  obvious 
critical  nature  of  the  mission  of  this  subsystem. 

At  present  the  entire  management  process  is  basically  in 
the  maintenance  mode,  characterized  by  a  basic  development 
cycle  of  approximately  18  months,  and  a  delivery  of  a  new 
release  to  the  fleet  every  twelve  months.  The  management 
process  is  also  capable  of  handling  more  than  one  release 
at  any  given  time,  so  that,  the  functional  specification 
phase  of  one  release  can  overlap  with  the  implementation 
phase  of  another,  with  the  V&V  activities  of  yet  another 
release  overlapping  with  both. 

Changes  and  release  planning  are  both  controlled  by  a 
Change  Control  Board  headed  by  SP-23  so  that  formal  configur¬ 
ation  management  control  is  exerted  on  this  process.  At  the 
present  time,  most  of  this  activity  is  concentrated  in 
changes  to  the  application  programs  and  only  occasionally 
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in  correcting  bugs  in  the  monitor  and  executives.  This,  of  course, 
would  change  drastically  if  a  modernization  program  were  to  get 
under  way. 
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6 . 2  Program; ' ing/Design  Practices 

A  good  documentation  of  the  actual  practices  used  in  the 
programming  and  design  of  the  Fire  Control  System  Application 
Tasks,  is  given  by  the  manual  NAVSEA  OD46099  "Trident  1  and 
Trident  1  Backfit  Fire  Control  System  Software  Programming 
Guidelines".  The  structure  of  this  document  is  as  follows: 

Section  I  Introduction 

Section  II  references  to  all  other  relevant  documentation 
Section  III  provides  an  overview  of  the  Fire  Control 
System 

Section  IV  presents  the  guidelines  for  programming 
and  designing  executives 

Section  V  gives  guidelines  for  the  programming 
and  designing  application  software  or  application 
tasks 

Section  VI  gives  the  guidelines  for  I/O 
Section  VII  presents  conventions  of  the  methodological 
type,  such  as  top-down  structured  programming,  top-down 
development,  etc.  That  is.  Section  VII  is  the  more 
traditional  programming  guidelines  material. 

To  give  the  flavor  of  the  guidelines  for  writing  executives, 
we  will  quote  a  few  below. 
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Page  4-19  Section  4. 2. 2. 2. 5  Processors  for  Memory  Assignment 

"When  executives  require  that  a  buffer  be  allocated  dynamically, 
they  must  communicate  this  request  via  the  memory  assignment 
processors.  The  monitor  will  call  the  appropriate  allocation/ 
deallocation  modules  to  honor  the  request.  Direct  executive 
communication  with  the  memory  allocation/deallocation  modules 
is  prohibited." 

Page  4-7  Section  4. 3. 1.2. 3  Waite  Continue  Functions 

"The  Waite  function  should  never  be  used  from  an  interrupt 
routine.  In  the  case  of  a  Waite  executive  action,  the  executive 
as  responsible  for  the  corresponding  Continue  function  and 
causes  the  transition  from  the  active/disabled  substate  to 
the  active/enabled." 

Page  4  ~  43  "  A.  An  interrupt  routine  can  never  suspend  itself 
by  using  the  Waite  macro  and  can  never  use  I/O  system  calls 
such  as  read/write  etc.,  with  the  Waite  option." 

Page  4-45  "Certain  generalities  about  the  nature  of  all 
executives,  however,  can  be  made.  First,  each  one  must  have 
a  "root"  segment.  (See  Figure  4-9.)  As  with  the  root 
segment  of  the  monitor,  the  root  segment  for  every  state 
executive  must  include: (  A  )  Executive  common,  (  B  )  The 
code  and  data  for  any  interrupt  routines  that  are  to  be 
directly  connected  to  the  DICS.  The  root  of  the 
executive  can  only  be  assembled  by  using  any  EBR  within 
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thc  range  of  four  to  seven.  (See  Table  4.1.)  Once  the  EBRs 
for  the  root  of  an  executive  have  been  established,  they 
cannot  be  used  to  span  any  portion  of  any  other  segment." 

Section  4. 4. 9.1  Stacks.  "No  program,  monitor,  executive, 
or  application  task  should  write  data  on  the  executive  stacks. 
These  stacks  are  used  for  linkage  information  only." 

Page  4  -  47  "VJhon  generating  the  loader  load  module,  it  is 
desirable  to  logically  concatenate  the  control  tables  of  all 
state  executives  to  the  control  tables  of  the  monitor. 

Since  the  virtual  origin  for  the  monitor's  control  tables 
is  BR-13,  disp' acement  0,  the  virtual  origin  for  the  control 
tables  for  all  state  executives  will  be  Bh-13,  displacement 
ALPHA,  where  ALPHA  is  the  length  of  the  monitor's  control 
tables. " 


A  few  examples  of  guidelines  for  the  writing  of  the  application 
tasks  follow. 

Page  5-6  Section  5.2.3.  Monitor  Task  Communication 

"A  :ask  desiring  services  from  the  monitor  (or  from  the  executive) 
must  use  an  EES  Call.  These  Calls  will  be  "procedures"  described 
in  the  THLI.  documentation." 
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Page  5-8  Section  5. 2. 4. 3  Tranf erring  Control  to  other  Tasks 

"A  ‘-ask  executing  under  a  state  executive  will  not  be  allowed 
to  jump  directly  to  another  task  operating  under  the  same 
executive.  It  will  be  required  to  return  control  to  the 
suato  executives  via  the  monitor,  which  in  turn,  will  relinquish 
control  to  the  second  task." 

As  it  can  be  seen,  these  guidelines  are  essentially  prescrip¬ 
tions  on  how  to  properly  use  the  services  of  the  monitor  in 
writing  executives  and  of  the  monitor  and  the  executives  in 
writing  application  tasks.  It  is  not  clear  from  this  documenta¬ 
tion  whether  these  rules  are  stated,  because  the  rules  are  enforced 
through  a  programming  discipline,  or  they  are  rules  which  are 
enforced  by  the  system  design  itself  and  are  listed  here  as  a 
reminder  to  programmers.  In  other  words,  what  we  are  saying 
are  that  a  number  of  these  rules  could  easily  be  implemented  as 
illegal  conditions  in  a  suitable  abstract  machine  of  the 
system.  We  are  not  clear  on  whether  tlis  has  been  done  or  one 
is  relying  largely  on  programming  conventions  to  impose  them. 

Section  VII  software  standards  and  conventions  starts  with 
a  very  nice  description  of  the  software  development  environment 
and  tools  in  this  program. 

Tn  Section  7.1.2. 1  Top  Down  Development  Testing,  the  manual 
explains  that  the  project  is  committed  to  the  use  of  standard 
top-down  development  method  and  furthermore,  it  indicates 
rhat  it,  indeed,  is  top-down  development  as  opposed  to  top-down 
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design,  in  fact,  it  says:  "the  top-down  approach  to  tost 
and  integration,  parallels  that  of  the  development  process, 
and,  in  fact,  overlaps  this  process.  Testing  is  a  continuous 
integration  of  a  consistently  growing  program.  The  first 
step  involves  execution  of  the  control  structure  only,  and 
then  building  the  program  in  the  sequence  previously  defined". 

As  if  is  well  known,  this  is  by  far,  the  best  way  to  develop 
and  test  programs  in  accordance  with  both  theoretical  insights 
and  extensive  positive  practical  experience. 

Section  7.1.3  Structured  Programming  Requirements  briefly 
explains  the  whole  concept  of  structured  programming 
methodology  and  makes  it  a  required  approach  for  this  program. 

Section  7.1.5  Trident  Program  Design  Languages  (TPDL) ,  states 
the  following:  "The  logic  for  a  program  will  be  represented 
i.n  TPDL.  For  Trident  software,  the  language  is  structured 
English  with  six  allowable  control  structures.  (By  the  way, 
those  arc  the  very  same  six  control  structures  which  are  allowed 
in  the  structured  coding  of  the  actual  programs.)  Indentations 
arc  required  to  show  the  various  levels  of  control.  To  show 
the  domain  of  a  structure,  three  additional  reserved  words 
are  used:  They  are  ENDIF,  ENDDO,  and  ENDCASE. 
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Statements  inserted  between  the  IF  and  ELSE,  ELSE  and  ENDIF,  DO  and 
ENDDO,  and  CASE  and  ENDCASE  must  be  so  indented  that  the  domain 
is  visually  recognizable." 

What  is  most  significant  of  this  approach  is  the  fact  that  the 
control  structures  are  exactly  the  same  as  that  of 
the  programming  language.  This  implies  that  the  outer 
syntax  of  the  Program  Definition  Language  is  the  same  as  that 
o:  the  programming  language  with  the  inner  syntax  being  an 
informal  English  like  language.  The  advantage  of  this  approach 
is  that  the  design  can  very  smoothly  evolve  through  refinements 
into  the  actual  programming. 

Another  interesting  point  is  made  on  Page  7  -  14  in  connection 
with  guidelines  for  top-down/structured  design.  One  of  the 
guidelines  is:  %  1  )  Partition  the  system  into  functions 
and  organize  related  functions  into  level  based  on  system 
usage  and  services  provided;  attempt  to  follow  LISKOV  level 
of  abstraction  and  partitioning  rules."  This  is  interesting 
because  it  shows  that  the  project  is  aware  of  the  notions 
introduced  by  LISKOV  on  level  of  abstraction  which  are  key 
to  the  proper  understanding  and  formulation  of  architectural 
design  of  complex  software  systems.  However,  the  rest  of  the 
documentation,  we  have  studied,  shows  no  real  distinction 
between  the  notion  of  structured  programming  and  that  of 
architectural  design,  so  it  might  be  that  the  understanding 
of  the  LISKOV  notions  is  not  sufficiently  profound. 
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In  summary,  these  guidelines  seem  to  be  quite  good,,  they  are 
basically  a  set  of  reference  informations  that  allow  the 
programmer  to  design  correctly  executives  and  application 
tasks,  and  a  set  of  methodological  prescriptions  which, 
basically,  recommend  the  use  of  all  the  latest  methodology. 
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6 . 3  Development  Environment 

By  development  environment  we  mean  the  run-time  support  of 
the  programming  language  as  well  as  all  of  the  other  tools 
which  are  required  for  the  generation  of  programs,  such  as, 
debuggers,  linkers,  loaders,  editors,  source  code  control 
systems,  etc. 

In  determining  how  many  development  environments  are  being 
utilized  by  a  project,  one  must  find  out  how  many  implementation 
languages  are  actually  being  used  and  how  many  machine/operat : ng 
systems  are  being  used  as  a  run-time  support  environment 
for  the  various  sets  of  tools.  In  the  case  of  this  program, 
it  appears  that  the  monitor,  all  of  the  GEOS  developed  test 
programs,  and  the  ASW  program  were  developed  in  assembly 
language  because  the  THLL  was  not  available  at  the  time. 

The  rest  of  the  software  is  devloped  in  THLL.  Thus,  from 
a  system  implementation  language  viewpoint,  one  would 
expect  two  basic  development  environments;  one  pegged  for 
the  THLL  and  the  other  for  the  assembler  for  the  TDCC . 

The  document  OD45986  "Trident  Software  Development  Plan", 
while  being  out  of  date  from  the  point-of-view  of  a  software 
development  plan,  sheds  considerable  light  on  the  issue  of 
the  development  environments  being  used  in  this  program. 
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Section  2.1.1  of  this  document  indicates  that  the  host  computers 
that  have  to  be  considered  include  the  CDC/6700,  G/635,  and  XDS 
SIGMA  5.  It  further  goes  on  to  indicate  that  there  is  a  variety 
of  programs  which  will  be  able  to  execute  on  all  of  the  host 
computers  and  that  they  are  all  characterized  by  being  written 

in  a  subset  of  the  ANSI  standard  FORTRAN  IV.  Amongst  these 
are  included  the  following: 

TASS:  Trident  Assembly  &  Simulation  System  (6700) 

This  system  includes  the  following  elements: 

TASS  Executive 

Control  Card  Pre-processor 

File  Editor 

Assembler 

Linker 

Instruction  Simulator 

TASS  (635)  This  system  includes  the  same  list  of  sub¬ 
systems  as  the  CDC/6700  version. 

TASS  (SIGMA  5)  This  system  includes  the  same  list  of  sub¬ 
systems  as  above. 

In  other  words,  what  we  seem  to  have  here,  is  a  portable  developmer 
environment  TASS  written  in  a  subset  of  the  ANSI  standard  FORTRAN 
IV  and  rehosted  in  the  following  computers:  CDC/6700,  GE/635, 

and  XDS  SIGMA  5. 
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Section  2.1.2  of  the  same  document  indicates  that  there  is 
a  version  of  the  Trident  Assembly  System  (TAS)  which  is 
written  in  Trident  Assembly  Language  and  that  this  particular 
system  has  exactly  the  same  list  of  subsystems  as  the  TASS 
stated  above  except  for  the  simulator. 

The  entire  collection  of  Trident  Assembly  Language  Programs 
which  basically  form  the  TDCC  hosted  development  environment 
is  as  follows: 

Check-out  Monitor 
On-line  Debugger 

-  TAS 

Trident  Loader 

TDCC  TAS  Accounting  Program 

-  SYSGEN 

-  TDCC  Support  Software  Quality  Test 
Utility  Package 

The  conclusion  we  are  driven  to  from  this  information  is  that 
the  complete  TDCC  assembly  language  development  environment 
is  replicated  in  two  forms;  one  is  a  set  of  subsystems  written 
in  FORTRAN  I’Aand  the  other  is  a  set  of  subsystems  written  in 
the  TDCC  assembly  language  itself. 
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7  • 0  Software  States  and  the  Operational  Sequence 

The  Real  Time.  operating  System  (RTOS)  of  the  TDCC  consists 
(u  .  any  one  time)  of  the  Monitor  pro-  ram  and  one  of  eight 
unique  fuck  Executive  programs.  The  Monitor  and  three  of 
the  Executives  are  written  and  maintained  by  the  Naval 
Surface  Weapons  Center  (NSWC) ,  Dahlgren,  Virginia.  The 
i  emuixing  five  Executives  are  written  and  maintained  by 
General  Electric  Ordnance  Systems  (GEOS),  Pittsfield,  Mass. 

I A  ninth  Executive,  used  for  ASW  Torpedo  Fire  Control ,  was 
writren  by  Librascope,  but  is  not  applicable  to  the  Trident 
'•’CS)  .  The  combinations  of  the  monitor  and  each  of  the 
•eight  executives  define  the  eight  operating  systems,  also 
called  stares.  The  names  of  the  executives  and  corresponding 
operating  sy  items  arc  identical: 


Executive  EEame 
D:La  Entry 

2.  Standby 

3.  Launch  (or  Tactical) 

4.  Test  and  Evaluation  (T&E) 

5.  Fire  Control  Test  (FCT) 

6.  Missile  Test  (MSL) 

7 .  Fuze  Test 

3.  Training  VJithout  Guidance 
{  DUMMY /TWOG,/ TWOG  I. ) 


Maintenance  Organization 


NSWC 


NSWC 


NSWC 

GEOS 

GEOS 

GEOS 


GEOS 

GEOS 
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Thc  first  three  operating  systems  will  be  described  first, 
as  they  relate  to  fire  control  modes  which  are  used  at  sea 
to  directly  implement  the  Trident  F/C  mission. 

When  the  submarine  is  at  sea,  in  a  patrol  area,  an  increased 
readiness  condition  is  set,  known  as  Condition  2SQ.  This 
condition  implies  that  the  submarine  can  achieve  a  battle- 
ready  condition  (1SQ)  in  a  relatively  short  time.  At 
1SQ  tiie  submarine  is  ready  to  launch  (or  simulate 
the  launch)  of  its  missiles  as  soon  as  the  Commanding 
Officer's  permission- to-f ire-switch  is  thrown. 

At  condition  2SQ,  both  TDCC ' s  are  normally  supporting  the 
Standby  F/C  mode  using  the  Standby  Executive.  In  this  mode, 
computational  programs  (including  9  unique  task  programs) 
arc  executed.  These  routines  are  described  below. 

During  condition  2SQ,  one  of  the  TDCC 1 s  can  be  switched 
by  the  operator  to  activate  the  Data  Entry  F/C  mode  using 
the  Data  Entry  Executive.  In  this  mode  data  processing 
programs  (including  three  unique  task  programs)  are  executed 
to  allow  the  operator  to  enter  mission  information  (targeting, 
geophysical,  system,  and  missile  data)  into  the  FCS  and  to 
insure  that  the  correct  data  is  stored  on  both  MDFs.  The 
main  functions  of  the  data  processing  routines  arc  performed 
in  the  following  order: 


a.  S.  (,' 


1.  Operator-initiated  input  of  data  (mission  information) 
from  data  sheets  and  magnetic  tape  cartridges.  Input 
to  the  computer  is  via  the  keyboard  and  MTFSS , 
respectively . 

t 

2.  Writing  and  storage  of  data  on  the  MDF  connected  to 
the  DCC  that  is  processing  data  entries. 

3.  Transfer  of  data  to  the  secondary  DCC  via  the  ICL 
and  storage  of  data  on  the  secondary  MDF. 

4.  Verification  of  entered  data  by  means  of  automatic 
and  operator-requested  printouts  on  the  computer 
printer. 

During  the  data  processing  state,  the  operator  is  also  allowed 
tc  modify  or  delete  previously  entered  mission  information. 

Operator  actions  associated  with  the  data  processing  state 
are  taken  in  accordance  with  standard  operating  procedures 
(SOP's).  During  performance  of  these  procedures,  the 
operator  must  ensure  that  both  disk  packs  installed  on  the 
MDF’ s  are  compatible  (i.e.  both  are  the  same  software  revision 
and  targeting  revision) . 

During  Standby  Mode,  the  standby  operating  system  and  standby 
program  are  loaded  into  DCC  main  memory  and  are  executed.  The 
main  routines  of  this  mode  are  a  computational  initialization 
routine,  a  range  check  routine,  trajectory  simulation  routines, 
and  an  onboard  footprinter  (OFT) .  These  routines  perform  the 
following : 
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Prepare  for  target  package  computations. 

Compute  the  simulated  flight  of  all  the  missiles 
in  each  of  the  designated  target  packages  to  their 
assigned  footprints  (burst  point  patterns) . 

Determine  if  each  footprint  is  achievable  from  the 
current  ship  position. 

Generate  footprints  from  data  entered  during  data 
entry  mode. 

In  order  to  achieve  battle  condition  1SQ  in  the  submarine, 
many  conditions  are  changed,  among  them: 

Tiie  submarine  crew  is  called  to  man  their  battle 
stations . 

The  submarine  itself  is  brought  to  launch  depth 
and  special  ballast  tanks  are  readied  for  missile 
launch  conditions. 

Trie  ship's  nuclear  propulsion  and  electrical  systems 
are  reconfigured  for  maximum  reliability. 

The  missile  firing  message  is  decoded  and  checked 
by  at  least  two  people. 

The  launch  tubes  are  pressurized  and  the  missile 
gyros  are  energized  and  stabilized. 

While  all  of  the  above  is  occurring,  the  Launch  (or  Tactical) 
operating  system  is  loaded  into  one  (or  both)  TDCC ' s  and  one 
of  three  possible  F/C  modes  are  selected: 
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Tactical  (TACT)  mode  for  firing  actual1  missiles. 

-  Training  with  Guidance  (TWIG)  mode  for  si:  uluted  launch. 
Training  with  Guidance  and  Launcher  (TWICL)  mo« e 
for  simulated  launch  (MK98  FC5  only) . 

The  launch  sequence,  whether  normal  or  simulated,  is  divided 
into  two  major  phases  or  conditions  of  readiness.  The  first 


phase 

is 

from  2 SQ 

to  1SQ  , 

and  the 

second  phase 

i  s  i  ro: 

a  ISO 

to  .V..I; 

.'S  .  ’ 

le  Away. 

Each  phi 

;so  consi 

.sts  of  a  sot 

o .  rou 

u  i  n  c  s 

( inoi; 

.id : 

UvJ  i  0  I'USk 

s )  t  ha  " 

execute 

Logo cher  to 

preps,  re 

and 

1  i  unen  :  iiss:i  !•  s.  These  routines  arc: 

Transition  computations 
Stellar  selection 

Platform  positioning  initial  velocity  computations 
Alignment,  erection,  and  elevation  check  routine 
Denote  routines 

The  transition  computations  develop  ta  'jeting  offsets,  time,, 
of  flight,  etc.,  required  for  each  missile  assigned  to  a 
footprint  in  the  active  target  package. 

The  stellar  selection  routine  selects  a  star  for  each  missile 
that  is  assigned  to  a  footprint  in  the  active  target  package. 
Once  selected,  this  star  is  available  for  a  predetermined 
amount  of  time.  At  the  end  of  this  time,  an  alarm  is 
displayed  on  the  operator  control  panel  and  the  missile  may 
be  restarted  ( 2SQ  to  1SQ)  by  reinitiating  the  guidance 
initialization  (GI)  sequence,  which  is  referred  to  as  re-GI , 
so  that  selection  can  be  restarted. 

<:.  S.  1  nc . 
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Tho  Platform  Positioning  Initial  Velocity  (PPJ.V)  computations 
routine  performs  platform  positioning  computations,  transfers 
the  PPIV  data  and  program  to  the  guidance  computer  (GC)  in  the 
missile,  and  performs  a  check  to  ensure  that  the  data  ,vas  sent 
correctly . 


The  alignment,  erection,  and  elevation  check  routine  controls 
the  transfer  of  navigation  data  to  the  missile  guidance  system 
(C.d)  and  evaluates  the  performance  of  the  guidance  platform 
positioning  sequence.  A  platform  positioning  complete  signal 
is  gcn-v  atn  d  in  the  missile  and  the  operator  control  panel 


a  the  1 


•a  i‘as;<  Control  Bus  (TCB)  indicating  the 


sequence  is  complete  for  that  missile  dV  1SQ) 


The  ISC  lo  missile  away  phase  consists  of  sequencing  a  missile 
ul  d  time  through  a  series  of  denote  and  prepare  routines. 

muring  denote,  the  routines  of  the  launch  state  perform  transis- 
tion  computations,  monitor  the  alignment,  erection,  and  elevation 
process,  and  keep  the  entire  weapon  system  updated  through  the 
launch  executive  interrupt  routines. 

During  prepare,  final  launch  preparations  are  completed  which 
arc  time  critical: 

Missile  presettings  {final  target  and  position  vectors) 
arc  sent  to  the  GS . 

Fuze  information  is  sent  to  the  missile  command  sequencer. 


<;.  S.  In.-. 


-34- 


Loops  open  sots  the  GS  inertial  and  transfers  the  GS 
to  internal  power. 

The  following  is  a  description  of  the  Test,  Evaluation,  and 
Training  states,  developed  and  maintained  by  GEOS,  ana  which 
are  not  normally  used  at  sea  during  patrol  conditions. 

The  T  st  and  Evaluation  (T&E)  state  is  used  to  support  shipyard 
installation  checkout  and  testing.  There  is  no  explicit  F/C 
mode  corresponding  to  this  state. 

The  Fire  Control  Test,  Missile  Test,  and  Fuze  Test  states  all 
execute  test  and  data  handling  programs  to  verify  that  the 
fire  control,  ruisiilo,  and  fuze  equipments  are  operational  or 
to  isolate  detected  failures  in  the  equipment. 

T,'ne  DUMMY /TWOG/TWOGL  state  provides  an  operator  interface 
simulation.  Operator  inputs  at  the  firing  panel  are  processed, 
firing  pane]  status  indications  are  raised  at  the  appropriate 
time,  keyboard  options  are  displayed,  and  errors  in  utilized 
equipment  are  detected  with  the  appropriate  alarm  printed 
and/or  indicated. 

The  following  table  summarizes  the  relationships  between  possible 
software  executives,  programs  executed,  and  fire  control  modes 
supported : 


V  In t. 


STATE 

CUTIVES 


Data  entry  Exec 


Standby  exec 


Launch  (or 
tactical)  excc 


'I’SE  exec 


FCT  test  excc 
MSL  test  excc 
'•UEE  test  cxe:: 


DUMMY /T. DG/TWOGL 
Uxec 
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PROGRAMS 

EXECUTED 


FIRE  CONTROL 
MODES 


1.  Data  Processing 

Programs  (3  tasks) 


1.  Data  entry 
mode 


2.  Computational  Programs  2.  Standby  mode 
(9  tasks) 


3 .  Launch  programs 
(10  tasks) 


Tactical 

Training 

guidance 

Training 

guidance 

launcher 


mode 

w/ 

(TWIG) 

w/ 


& 

(TWIGL) 


Test  &  Evaluation 
programs 


5.  Test  programs  and 
data  handling 
programs 

6 .  DUMMY/ rWOG/TWOGL 
programs 


6.  FC  test  mode 

7.  MSL  test  mode 
3.  FUZE  test  mode 


9 .  DUMMY /TWOG/TWOGL 
modes 
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CDRL  # AO 05 

8 . 0  Additional  Processing  Requirements  for  the  Applications 

In  this  section  of  the  report,  we  will  examine  the  opportunities 
for  extending  the  architecture  of  the  TDCC  to  accommodate 
additional  requirements.  We  will  start  the  section  by  an 
extensive  review  of  the  many  studies  that  have  been  performed 
by  LISWC,  CEOS,  and  IIAC  on  this  general  subject. 

The  latter  part  of  this  section  presents  our  views  on  how, 
in  light  of  the  available  evidence,  we  would  recommend 
evolving  the  architecture  of  the  system. 

The  evidence  available  to  us  on  the  subject  is  somewhat 
Limited.  The  limitation  arising  from  two  fundamental  factors, 
the  first  being  the  obvious  secrecy  that  surrounds  this  kind 
of  program,  the  second  being  that  the  project  community  has 
been  less  than  favorably  inclined  t.  meet  in  an  open,  round 
table  mode  of  discussion,  on  this  subject  matter.  What  we 
arc  saying  is  not  that  the  project  team  has  deliberately 
avoided  contact,  quite  the  contrary,  we  were  briefed  on  a 
number  of  occasions,  however,  there  has  been  a  feeling  on 
the  part  of  the  project  team  that  GSG  could  not  really  do 
much  to  help  them  and  consequently,  it  was  almost  a  waste 
of  t ' me  to  sit  down  and  talk  about  difficult  problems. 

Wc  regret  that  this  has  happened,  since  our  study  of  the 
available  written  evidence  shows,  in  an  undeniable  wny,  that 
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the  community  support i no  this  program  has  limited  computer 
system  architecture  capabilities,  and  that  it  has  struggled, 
for  aver  three  years,  with  problems  that  a  competent  system 
arch  i  toot  could  have  solved  in  mac:,  less  time.  Furthermore , 
;i udo :  no  1  i*om  the  most  recent  document s  available  t  o  .s, 
the  \>v  yjeet  i  s  still  headed  in  the  wreno  direct  ion  and 
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options  for 

memory 

add  re  stability  dated  October  11,  1979.  Finally,  the  last 
so  t  of  data  was  the  one  wo  obtained  durir..j  the  JSC-  Proa  ram 
deview  in  daalarer.  on  dune  10  it,  1.9b  0 . 

These  sources  of  information,  of  course,  are  reviewed  strictly 
from  the  point-of-view  of  what  evidence  they  offer  for  increased 
requirements  in  either  computational  power,  memory  sire 
and  addressability,  or  mass  storage  performance  and  capacity 
Fn  other  words,  only  for  evidence  that  they  may  of f^r  for 
the  need  i  or  a  rovist.i  architecture  of  .he  FCS  system. 
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Contract  #N000 14-80-C-010 
CDRIi  if  AO  05 


8.1  November  10,  1977  Throughput  Working  Group  Meeting 

This  is  the  first  set  of  minutes  of  the  working  g : cup  in  our 
possession.  It  shows  that  most  of  the  preoccupation 
or  the  group  is  centered  around  the  computational  requirements 
posed  by  the  High  Frequency  Gravity  (HFG)  compensation .  As 
v:o  sh.al  1  see,  i.FG-  dominates  the  discussion  also  of  the  other 
three  sets  of  minutes. 

Curing  this  meeting,  tivec  methods  for  performing  the  HFG 
calculations  are  discussed.  They  are  the  Stokes  integral , 
the  Coat.iv;  Lnteura.1,  and  the  hois  sen  (upward  method)  technique. 
A  very  import  a  n.t.  point  in  these  minutes  is  that  it  appears  that 
this  is  the  first  time  that  the  group  .-.as  discussing  the 
possibility  of  catting  down  by  an  order  of  magnitude  the  number 
cf  v . otors  to  be  computed.  In  fact,  evidence  is  being 
pr  osented  that  seme thing  like  18  vectors  would  achieve 
acceptable  accuracy.  Thu  reduction  of  the  number  of  vectors 
Is  obtained  by  util  icing  a  saline  fitting  approximation 
scheme  with  only  a  limited  number  of  data  points,  namely, 
the  vectors  to  be  computed.  'the  minutes  explicitly  comment 
that  the  accuracy  achieved  is  the  same  as  that 
previously  expected  to  require  something  like  100 
v oc  L'u  rs  . 

The  minutes  also  reflect  the  understanding  that  improvements 
of  the  compulation  of  the  Waiting  Matrix  (W-Matrix) ,  regard¬ 
less  what  factors  are  chosen  to  be  improved,  imply  no 
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siun i  f  icur. t.  .increases  of  the  throughput  of  the  Basie  Processor 
(BP).  This  further  stresses  the  point  that,  as  far  as  computa¬ 
tional  needs  are  concerned ,  the  only  problem  that  seems  to  be 
eenfronei.au  'the  work  inn  a  roup  is  '.!F0 . 
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v  a  Lira  that  it  is  extremely  interesting  to  us,  as  computer 
to;;i  arehicects,  is  that  the  minutes  include  a  view  graph 
ev;  Jruph  5)  which  actually  presents  the  instruction  mixes 
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:'h:s  toaotker  with  similar  ether  pieces  of  evidence  indicate 
to  us  t.uV.  the  people  wire  are  involved  in  doing  this  kind  of 
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considerable  amount  of  professional  training 
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in  learning  how  to  control  the  error  accuracy  of  their 
algorithms  to,  sometimes,  well  less  than  1%  error.  To 
carry  over  this  kind  of  mentality  to  system  architecture 
is,  not  only  a  waste  of  time,  because  a  lot  of  work  gets 
done  that  should  not  have  been  done,  but  it  is  actually 
harmful,  because  it  causes  the  whole  conceptual  landscape 
of  the  problem  to  get  cluttered  with  a  lot  of  details 
which  are  totally  irrelevant. 

To  substantiate  our  point  in  this  specific  case,  one  has 
only  to  refer  to  View  Graph  5  to  see  that  the  differences 
between  instruction  mixes  are  absolutely  negligible.  In 
fact,  the  only  significant  differences  are  in  the  fixed 
point  arithmetic  and  floating  point  arithmetic.  In  the  case 
of  fixed  point  arithmetic  the  point  mass  method  appears  to 
require  three  times  the  frequency  of  fixed  point  arithmetic 
instruction  that  either  Stokes  or  Coating,  on  the  other 
hand,  the  point  mass  method  requires  approximately  60%  of 
the  floating  arithmetic  instructions  that  either  Stokes 
or  Coating.  Furthermore,  Stokes  and  Coating,  for  all 
practical  purposes,  have  exactly  the  same  instruction 
mix.  The  other  point  is  that,  even  these  two  significant 
differences,  do  not  amount  to  much  more  than  about  10% 
of  the  total  instruction  mix. 

On  View  Graph  8-12,  the  computational  times  for  the  three 
methods  are  given  for  both  the  case  of  single  missile 
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and  for  all  24  missiles.  The  computation  times  are  given  also 
for  a  six  point  spline  and  a  five  point  spline.  The  key 
message  that  comes  across  from  this  slide,  from  a  computer 
system  viewpoint,  is  that  the  Stokes  method  requires 
approximately  twice  the  computation  of  Coating  which, 
in  turn  requires  approximately  10  times  the  computation 
of  the  upward  method.  In  other  words,  from  a  system 
architecture  point-of-view,  it  is  very  clear  from  this 
data  that  the  choice  of  the  numerical  algorithm  affects 
the  architecture  in  significant  ways. 

Next  the  meeting  examined  a  throughput  estimation  study 
which  presents  a  lot  of  numerical  results  in  the  form 
cf  performance  curves.  The  study  was  done  with  a  number 
of  assumptions.  The  three  key  ones,  from  our  pcinc-of- 
view,  being  as  follows: 

Workload  to  be  the  sum  of  the  Trident  I  computational 
workload  plus  the  Trident  II  unique,  which  is  HFG. 

Similar  software  architecture  to  that  of  Trident  I. 

HFG  would  be  computed  using  the  upward/point  mass 
technique . 

We  would  like  to  briefly  summarize  only  a  portion  of  the  results 
because  they  are  important  to  make  a  very  specific  point  later  on. 
The  two  sets  of  results  we  would  like  to  summarize  are  the 
estimates  of  throughput  (in  Kips)  for  tho  case  that  the  HFG 
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computation  is  done  during  the  launch  interval.  For  the  purpose 
of  illustration,  we  will  assume  that  the  launch  interval  is  20 
seconds  (end  of  the  range  of  the  curves) .  Similar  results  for 
the  case  in  which  the  HFG  computation  is  done  during  the  transi¬ 
tion  interval,  again,  for  illustration  purposes,  we  assume  that 
interval  to  be  20  minutes  (end  of  curve's  range).  The  numerical 
results,  which  were  read  by  us  from  the  curves  in  a  very 
approximate  way,  are  summarized  in  the  Figures  8.1-1  through 
8.1-4.  The  first  thing  that  is  apparent  from  these  numbers  is 
that,  from  an  architectural  point-of-view,  one  should  not 
worry  about  I/O  contention  since  it  does  not  seem  to  make 
a  significant  difference.  As  one  can  see  from  the  figures, 
the  effect  of  varying  from  max  to  min  I/O  contention  is 
less  than  151,  which  is  insignificant  in  architectural  terms. 
This  conclusion  that  could  have  been  arrived  at  in,  as  far 
back  as  November  1977,  was  actually  eventually  arrived  at 
by  the  working  group  well  over  a  year  later. 

The  other  point,  that  is  obvious  from  these  computations, 
is  that  since  the-  present  TDCC  rated  throughput,  in  Kips 
of  Numerical  Mix  (N-Mix) ,  is  182  Kips  for  the  case  of 
minimum  I/O  contention  and  156  Kips  for  the  case  of 
maximum  I/O  contention,  it  is  obvious  that  even  the 
upward/point  mass  technique  that  is  being  used  for  this 
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throughput  estimation  requires  a  computer  which  is  signifi 
cantly  more  powerful  than  the  one  presently  on  hand. 

The  key  point  is  that  computing  systems  cannot  be  designed 
to  utilize,  on  a  steady  state  basis,  100%  of  the  resources 
The  reason  for  this  is  that  they  are  basically  complex 
queueing  systems.  A  queueing  system  will  break  down  once 
the  steady  state  rate  of  resource  utilization  exceeds 
the  70%  level.  By  the  way,  this  is  the  true  explanation 
of  the  software  stabilization  factor  that  this  project 
uses.  If  a  throughput  of  about  550  Kips  is  required, 
this  means  that  the  machine  should  be  capable  of  a  rated 
throughput  of  at  least  0.75  MIPS  (Million  Instruction  Per 
Sec)  . 

In  view  of  the  fact  that  at  this  very  same  meeting,  the 
conclusion  had  been  drawn  that  the  upward  method  was  the 
one  that  required  the  least  amount  of  computation  and 
that  methods  such  as  Coating  and  Stokes  would  require  an 
order  of  magnitude  more  computation,  it  should  have  been 
very  clear,  way  back  in  November  1977,  that  a  completely 
redesigned  compu  or  was  called  for. 

Furthermore,  with  the  technology  picture  that  we  had  back 
in  L977,  it  would  have  been  clear  to  anybody  competent  in 
Siunmu  computer  systems  that  a  reimplementation  of  the 
t:j<V  to  obtain  a  full  order  of  magnitude  improvement  of 
throughput  would  have  been  possible. 


A.  .  I nr. 


study  itself  draws  the  following  conclusions  (View  Graph  14) 


Throughput  consideration  place  gravity  computation 
in  the  transition  interval. 

Minimal  impact  on  throughput  due  to  I/O  contention, 
and  weighting  (refinement,  offloading). 

Significant  impact  due  to  the  number  of  high 
accuracy  missiles,  and  tne  percent  of  gravity 
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8.2  January  24,  1978  Throughput  Working  Group  Meeting 

This  meeting  was  completely  dominated  by  the  HFG  question,  and 
it  devoted  most  of  its  time  to  the  presentation  of  a  very  large 
number  of  architecture  alternatives  for  the  Trident  II  FCS 
Computer  System.  The  fact  that  HFG  dominates,  actually  better 
said,  swamps  everything  else,  is  illustrated  very  clearly  by  a 
computational  load  analysis  that  is  presented  in  the  minutes  of 
this  meeting.  This  analysis  shows  that  the  number  of  milliseconds 
of  computation  required  out  of  each  second  of  elapsed  time  is 
given  by  a  formula  as  fellows: 

COMP  LOAD  (TDCC  )=( 3 32+  ---?— °-)  msecs/sec 

-Li 

where:  L=Launcn  interval 

Prom  this  formula  it  is  easy  to  see  that  the  launch  interval  has 
to  be  at  least  56  seconds  to  make  the  above  equation  come  out  to 
1000  miliseconds/sec .  V.hat  this  means  is  that,  assuming  for 
instance  that  20  seconds  is  the  ideal  launch  interval, 
that  the  TDCC  is  at  least  three  times  less  powerful  than  required. 
Actually,  this  is  even  worse  because  as  we  stated  before,  the 
computational  power  or  the  BP  should  not  be  utilised  at  more 
than  701  steady  state  level,  which  means  that  a  TDCC  would 
turn  out  to  be  more  than  four  times  less  powerful  than  desired. 


What  is  really  interesting  about  this  computation  is  that, 
the  dominant  factor  of  the  above  formula  is  the  factor 
37550/L.  This  factor,  in  turn,  decomposes  as  follows: 

37550=2750  (transition  computation)  +  4800  (prepare  tasks 
and  disk  waits)  +  30000  (HFG) 

In  other  words,  of  the  37,550  units,  30,000  are  due  to 
IIFG,  which  means  that  for  all  reasonable  launch  intervals, 
the  computational  load  associated  with  HFG  will  swamp 
anything  els a. 

Another  interesting  thing  to  note,  in  the  minutes  of  this 
meeting,  is  that  values  for  the  TDCC  throughput  are  given 
for  the  following  instruction  mixes:  N-Mix  =  182,  point 
mass  =  170,  layer  =  1 6_ ,  upward  =  163,  Stokes  =  157.  The 
largest  difference  between  these  throughput  numbers  is  that 
which  exists  between  the  N-Mix  and  the  Stokes  mix.  This 
difference  is  132-157=25  which  is  only  145  of  the  value 
of  the  N-Mix  to  begin  with.  As  we  stated  repeatedly  before, 
a  difference  of  the  order  of  15%  in  data  processing  require¬ 
ments,  is  below  the  level  of  architectural  significance. 

Our  Figure  8.2-1  summarizes  the  throughput  figures,  in  Kips 
for  three  basic  processors  which  are:  the  TDCC,  the  SBP  9900 
with  hardware  floating  point,  and  the  AMD  2900  bit  slice  with 
hardware  floating  point.  These  throughput  figures  are  given 
for  various  instruction  mixes  just  as  we  mentioned  above 
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with  regard  to  the  TDCC.  An  analysis  of  these  figures  shows 
that  for  the  SPP  9900,  the  maximum  delta  between  throughputs 
for  tho  different  instruction  mixes  amounts  to  a  26-S  variance, 
and  for  the  2900  bit  felice  processor  it  amounts  to  27.53.  That 
is,  for  these  latter  two  processors,  the  differences  begin  to 
get  into  the  threshold  of  significance  but  they  are  still  very 
m a rg i na 1 1 y  si g n i f i c  an t . 

View  Graph  B-.L8  shows  that  the  SB?  9900  executing  any  of  the 
four  iiFG  algorithms  (point  mass,  layer,  upward ,  and  Stokes) 
exceeds,  for  24  missiles,  the  readiness  constraint 
ror  the  transit.;  on  interval.  Therefore,  the  conclusion  is  that 
this  micro  processor  could  not  handle  the  HFG  computation,  that 
is,  that  the  simple  addition  of  such  a  micro  processor  is  not 
the  answer. 

View  Graph  3-19  shows  the  numbers  for  the  case  in  which  the  HFG 
computation  is  shared  between  the  TDCC  and  the  S3P  9900.  These 
numbers  happen  to  fall  within  10  to  15s  from  the  numbers  that 
•would  result  with  the  TDCC  alone,  and  again,  in  all,  but  the 
layer  method ,  exceed  the  constraint  for  the  transi¬ 
tion  interval.  The  conclusion  that  is  drawn  from  the  two 
View  Graphs,  B-18  and  B-19,  is  that  a  single  (referred  to  as 
monolithic)  SBP  9900  micro-processor  added  to  the  TDCC  will 
not  help. 

Having  drawn  this  particular  conclusion,  the  study  proceeds  to 
explore  a  number  of  distributed  architectures.  Basically  the 
rationale  beinu  that  if  one  micro  processor  can  not  do  the  job, 
one  can  exp) ore  the  possibility  of  adding  several  micro  processors 
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cooperating  to  give  the  computational  power.  The  basic  approaches 
that  are  considered  are  two,  one  is  to  missilize  the  micro  pro¬ 
cessor,  that  is,  dedicate  a  micro  processor  to  each  missile  to 
do  the  ZIFG  computation.  The  other  approach  is  to  partition  the 
computation,  that  is,  to  partition  the  algorithm  into  phases  that 
can  be  independently  computed.  If  N  independent  phases  can 
be  partitioned  out  of  the  algorithm,  then  N  micro  processors 
could  be  kept  busy  increasing  the  throughput  by  almost  the  same 
factor. 

In  the  event  of  che  raissilized  micro  processor,  the  computa¬ 
tional  tine  for  2  4  miss:  Lm  is  equal  to  that  for  one.  That 
is,  Stokes  -•  73.3  minutes,  point  mass  =  5.03  minutes,  layer  =  1.7 
minutes,  upward  =  11.54  minutes.  Data  access  requirements  are 
shown  to  bo  within  the  range  of  GO  kilowords  to  120  kilowords, 
with  a  total  data  transfer  delay  amounting  to  somewhere  between 
.3  to  .5  minutes,  which  obviously  is  negligible.  This  last  piece 
of  Information  is  interesting  because  it  confirms  that  the  HFG 
problem  is  strictly  a  compute  bound  problem. 

Those  results  for  the  SEP  9900  obviously  indicate  that  all  methods, 
except  the  Stokes  integral  method,  are  feasible,  in  the  sense  of  not 
violating  the  constraint  for  the  transition  interval . 

The  second  approach  to  r  distributed  architecture  is  really  not 
carried  very  far,  since  information  with  regard  to  the  partitioning 
of  the  algorithm  is  not  on  hand. 
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Noxt,  tlio  architecture  study  turns  to  explore  the  possibilities 
that  could  arise  from  the  AMD  2000  bit  slice.  It  basically 
predicates  a  32  bit  wide  processor  based  on  this  bit  slice 
component  and  in  View  Graph  B-27,  gives  the  corresponding 
data,  on  the  nssumpt ion  that  all  of  the  HFG  computation 
would  be  do. .a  : >v  this  •  !  iary  processor. 

Figure  8 . 2.  -  2  si>-  .ws  elv  •<  >:  •  -at  it  ion  time  in  minutes  for  the 
four  HFG  ale  rut  •.  <  i  ;  rst.  coiumn  shows  some  numbers  we 

obtained  from  tut  in  .  r::  data  of  view  Graph  B-18  and  multiplying 
it  by  the  simple  N -  .  i : :  .  ips  '..tio  for  the  SBP  9900  (  35  Kips) 

and  that  of  the  VMM  290  3  bit  .'.lice  processor  (309  Kips).  The 
second  column  shows  the  independent Ly  computed  data  given  on 
V’  ow  Grata  B-27.  it  can  be  seen,  the  agreement  is  extremely 

good.  For  all  practical  purposes  all  tae  work  that  is  behind 
View  Graph  B-27  did  not  need  to  be  done  in  the  first  place. 

Figure  8.2-3  shows  the  same  comparison  for  the  case  for  the 
missilixed  version  of  AMD  2900.  Again,  the  agreement  between 
the  computation  time  shown  in  View  Graph  B-29,  which  appears 
to  be  independently  computed ,  and  that  which  we  computed  from 
the  data  of  B-18,  is  extremely  good  and  for  all  practical 
purposes,  it  is  the  same  data.  In  this  figure,  we ,  for  the 
first  time,  show  under  the-  B-29  data,  also,  the  delays  due  to 
the  lata  transfers  (the  other  set  of  numbers  after  the  slash) . 

In  other  words,  it  is  only  when  one  gets  to  the  point  of  assuming 
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a  missile-dedicated  processor  (m.issilizcd  2900)  which  is 
twice  as  powerful  as  the  current  TDCC ,  that  the  data  transfer 
delays  become  a  significant  portion  of  the  computation's 
claosea  tamo. 

'this  is  another  way  to  say  that  one  does  not  need  to  worry 
about  the  delay  in  data  transfer  time,  since  it  seems  very 
unlikely  that  one  would  solve  this  problem  by  dedicating  to 
each  missile,  a  processor  twice  the  power  of  the  current 
Fire  Control  orocossor,  in  fact,  there  arc  better  ways  to 
solve  this  problem  than  this  kind  of  overkill. 

Another  thing  that  on.,  can  read  from  the  data  presented  in 
Figure  3.2-2  and  3.2- 3  is  that  the  Stokes  method,  at  least 
as  predicated  j.n  this  particular  study,  is  clearly  the  wrong 
approach  to  solve  the  problem.  In  fact,  even  after  getting 
to  the  kind  of  over kill  represented  by  Figure  3.2-3,  the 
Stokes  method  still  takes  3:,  minutes. 


The  di str  i  bn  ted  architecture,  using  *  he  AMD  2900  that  would 
resul  ‘  by  par  t  it  ion:  an  the  I1FG  algorithms  into  phases  is  not 
further  ii.-.-d  a  -j  because,  of  course,  no  knowledge  was  present 
.A:  the  ,  ibou*  potential  phases  of  these  algorithms. 
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A  couple  of  additional  cases  involving  the  AMD  2900  are  presented, 
both  of  them  assume  special  instructions  in  micro  code,  resulting 
in  about  a  thirty  per  cent  improvement  of  throughput.  One 
case  is  the  monolithic  auxiliary  processor,  and  the  other  case 
is  the  missilized  processor.  These  two  cases  are  not  even  worth 
discussing  because,  as  we  stated  repeatedly,  thirty  per  cent  is 
at  the  marginal  significance  level  as  far  as  architecture  is 
concerned . 


finally  i:hc  study  winds  up  by  suggostino  alluding  to  the  possi¬ 
bility  of  using  an  auxiliary  processor  which  would  be  a  special 
purpose-  processor,  namely  an  array  type,  of  processor,  which  of 
course,  would  have  the  intrinsic  paralielisig  in  three  dimensional 
space,  of  performing  simultaneously  operations  on  the  three 
coordinates  and  therefore,  potentially  being  able  to  compute  three 
times  as  fast  as  a  conventional  scalar  oriented  processor. 


I 
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we  are  very  puzzled  by  this  entire 


performance,  since 


the  idea  of  complicating  the  system  design  by  introducing  N  micro¬ 
processors,  one  for  each  phase  of  a  partitioned  algorithm,  or  worse 
yet,  24  processors,  one  for  each  missile,  would  introduce  so  many 
other  complications  is  terms  of  either  the  physical,  electrical 
connectivity  of  the  system,  or  the  system  software  to  handle  all 
of  this.  Such  complexity  seems  to  be  totally  unnecessary,  because 
of  the  following  reasons: 


a.  It  is  not  that  difficult  to  design  a  processor  which  is 

software  compatible  to  a  previous  one  and  has  a  performance 
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« 


improvement  of  at  least  threefold  and  most  likely, 
up  to  a  full  order  magnitude.  This  is  routinely 
done  by  computer  manufacturers,  as  part  of  their 
design  of  product  lines,  and  their  evolution  to 
track  marketplace  cost  performance. 

2.  The  wide  spread  in  the  computational  times  of 
the  proposed  algorithms  would,  in  our  opinion, 
be  priir.a  facie  evidence  that  the  root  of  the 
problem  is  the  algorithm  that  is  being  proposed, 
’hat  is  that  a  good  hard  look  at  its  complexity 
and  whether  it  is  really  needed  would  probably 
be  the  best  pav-off  direction  to  go. 


(  !.  S.  <  ,  I  nr. 


-107- 


Contract  #N00014-80-C-0104 
CDRL  #A005 


8 . 3  June  21,  197 8  Throughput  Working  Group  Meeting 

The  minutes  start  by  stating  the  two  fundamental  questions 
as  follows: 

a.  Given  the  present  processing  capability  of  the 
Trident  I  FCS ,  how  long  will  it  take  to  perform 
the  task  on  hand  (i.e.  existent  Trident  I  tasks 
plus  HFG) ? 

b.  Given  the  projected  Trident  IT  computational 
task,  how  much  more  processing  capability 
(instruction  throughput j  '.-.•ill  it.  be  required  to 
complete  it  m  a  l  m.neh  :  n^orval  which  is 
seconds  long,  or  m  a.  ir  ns  it  ion  interval 

that  is  x  minutes  Ion.  7 

The  studios  presented  in  this  urti.-ular  set  of  minutes 
finally  use  only  the  N-nix  (i.e.  no  Stakes,  layer,  etc., 
specific  mixes).  Evidently,  by  this  point  in  time,  the 
project  had  realized  that  the  difference  between  the  mixes 
was  not  significant. 

It  is  also  stated  explicitly  that  at  a  transfer  rate  of 
500  kilowords  per  second,  the  I/O  contention  degradation 
of  the  TDCC  N-mix  is  empirically  established  to  be  15%. 

This  confirms  our  previous  statement  that  this  problem  of 
I/O  contention  is  not  architecturally  significant,  at  least 
not  for  the  HFG. 
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The  minutes  also  have  a  lengthy  discussion  of  the  software 
stabilisation  factor  that  is  used  to  increment  the  various 
estimates  of  throughput.  The  rationale  for  this  factor  is 
that  empirical  evidence  shows  that  software  development  and 
maintenance  costs  grow  very  rapidly  once  computer  resources 
are  utilized  at  a  level,  quoting  from  the  minutes,  higher 
than  75  to  85%.  This  is  indeed  true  and  it  is  a  wise 
move  in  making  these  estimates  of  processing  capacity 
to  utilize  an  augmentation  factor.  We  would  recommend  an 
even  more  conservative  approach  that  is  justified  by  truly 
understanding  the  reasons  for  this  phenomena.  In  fact, 
this  phenomena  of  escalating  costs  is  due  to  the  nature 
o*  computing  systems  being  systems  of  queueing  servers. 
Queueing  servers,  if  they  are  forced  to  operate  under 
stochastic  conditions  with  a  steady  resource  utilization 
level  in  excess  of  70%,  saturate,  causing  all  kinds  of 
strong  interactions,  and  system  break-down  conditions 
to  occur.  In  light  of  this  kind  of  theoretical  under¬ 
standing  of  the  reason  why  the  software  costs  go  up,  it 
is  prudent  to  use  a  capacity  augumentation  factor  of  30% 
or  more.  This,  by  the  way,  is  the  reason  why  we  have 
repeatedly  made  the  statement  that  30%  is  kind  of  the 
border  line  of  significance  as  far  as  architecture  is 
concerned.  The  point  being  that  capacities  in  a  computing 
system  must  be  viewed  as  "fuzzy"  quantities  which  have  to 
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have  ouilt-in  a  (fuzzy)  slack  interval  of  the  order  of  30% 
to  accommodate  the  staiistic/stochastic  nature  of  the  work 
load . 

So  we  applaud  the  wisdom  of  the  "software  stabilization  factor 
but  we  are  disappointed  by  its  rationalization  showing  a  lack 
of  understanding  of  the  underlying  phenomena  and  resulting 
in  a  value  for  it  which  is  too  low , 

The  meeting  was  primarily  concerned  with  the  refinement  of 
the  throughput  study.  The  latter  considered  only  the  HFG 
requirements.  As  we  have  seen  previously,  HFG  requirements 
completely  swamp  everything  else  so  that  this  restriction 
does  not  invalidate  the  study.  Before  commenting  on  the 
study  per  se  ,  we  would  like  to  present  the  study  conclusions. 

a.  The  computational  techniques  (Stokes,  Coating, 
upward)  is  the  most  significant  factor  affecting 
the  required  throughput. 

b.  Stokes  and  Coating  require  significantly  more 
throughput  than  what  is  available  in  the 
Trident  I  FCS. 

c.  The  upward  continuation  method  is  feasible 
within  the  available  computing  power  but  no 
spare  capacity  would  be  left. 


.v.  r;„  /•. 
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d.  A  significant  reduction  of  throughput  is  alleged 

in  connection  with  the  weighted  case  which  reflects 
the  impact  of  off-loading  periodic  tasks  from  the 
TDCC  to  some  other  processor.  That  is,  a  benefit 
is  claimed  for  a  distributed  Fire  Control  Architecture. 

Frankly,  as  we  will  comment  below,  this  off-loading 
is  not  sufficiently  explained  to  warrant  any  such 
rosy  conclusion  about  distributed  architectures. 

e.  Less  throughput  will  be  required  if  HFG  will  be 
done  during  the  transition  interval  as  opposed 
to  the  launch  or  fire  interval. 

f.  The  impact  of  I/O  contention  is  not  very  significant. 

g.  Some  reduction  of  throughput  will  result  by  reducing 
the  number  of  data  points  for  the  spline. 

h.  The  ro-GI  assumption  has  a  minimal  impact  on  the 
throughput  requirements. 

By  and  larg  ,  these  are  the  first  set  of  sensible  conclusions 
we  have  seen  in  this  entire  set  of  studies,  and  the  proof 
that  could  have  been  gotten  much  sooner  is  that  when  we 
studied  the  minutes  of  the  working  group,  we  read  and  commented 
on  them  in  historical  order,  that  is  starting  from  the  oldest  one 
first  and  before  reading  the  most  recent  ones,  including  this 
one,  we  had  achieved  exactly  the  same  conclusions  with  an 
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infinitesimal  fraction  of  the  effort  that  probably  went  in 
doing  all  of  this. 

The  study  itself  presents  a  very  large  number  of  graphs  of 
the  type  that  were  used  also  in  previous  studies.  All  of 
the  graphs  presented  assumed  that  the  effect  of  the  gravity 
field  perturbation  after  the  boost  is  neglected,  and  also 
that  the  computational  method  is  based  on  the  spline  fitting 
through  6  points. 

We  will  only  mention  a  few  numerical  results  from  the 
basic  case.  They  indicate,  again  reading  the  curves  in 
a  very  approximate  way,  that  for  a  20  seconds  launch/fire 
interval,  (end  of  curve's  range)  the  throughput  required  by 
the  three  methods  under  consideration,  is  as  follows;  Stokes 
1250  Kips,  Coating  700  Kips,  upward  180  Kips.  Similarly,  the 
throughput  required,  if  the  HFG  calculation  is  done  during  the 
transition  period,  and  assuming  a  transition  period  of  20  minutes 
(end  of  curve's  range)  turns  out  to  be  Stokes  500  Kips,  Coating 
300  Kips  and  upward  120  Kips. 

In  addition  to  the  basic  case,  the  study  presents  a  weighted 
case  which  uses  an  off-loading  factor  (off-loading  periodic 
tasks  from  the  TDCC  to  some  other  processor) .  This  off-loading 
factor  is  not  sufficiently  explained.  Additional  cases  are 
generated  by  considering  an  enhancement  factor  (refinement  of 
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certain  existing  computational  tasks) .  This  factor,  too, 
is  not  sufficiently  explained  or  defined.  Finally,  additional 
cases  result  from  introducing  the  so  called  software  stabliza- 
tion  factor.  Having  introduced  all  of  these  different 
corrective  factors,  the  study  proceeds  to  generate  graphs 
for  all  possible  permutations. 


.V  O'..  I  nr. 
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8 . 4  April  6,  19  79 _ Throughput  Working  Croup  Meeting 

The  minutes  of  this  particular  meeting  show  that  the  next 
working  group  meeting  was  tentatively  scheduled  for  May/June 
1979.  We  presume  that  this  meeting  never  cane  off  since 
we  were  not  given  the  minutes  of  any  other  meeting  beyond 
the  .April  6,  197  9. 

Also  cheso  minutes  are  the  first  time  when  the  Trident  I  Upgrade 
Program  is  ever  mentioned  as  a  possible  way  station  to 
the  Trident  II.  We  road  both  of  these  two  elements  to  mean 
that  back  into  the  spring  of  .1979  the  commitment  to  the 
Trident  II  Program  was  beginning  to  weaken .  So,  probably, 

'-.acre  have  bc.cn  r.o  more  working  group  meetings.  In  fact, 
che  eventual  cancellation  of  the  Trident  II  Program 
and  replacement  of  it  with  a  C4  Upgrade  Program  would  remove 
the  pressure  from  the  implementation  of  the  HFG  feature. 

In  connection  with  the  discussion  of  the  Trident  I  Upgrade 
as  a  way  station  to  the  Trident  II  Program,  is  stated  that 
the  "ire  Contol  System  could  begin  the  evolution  towards 
a  distributed  architecture  in  the  Trident  I  Upgrade. 

The  basic  point  seems  to  be  that  the  results  of  the  analyses 
presented  at  the  June  21,  1978  meeting,  subsequent- 
work,  and  discussions  must  have  convinced  people  more  and 
more  that  a  distributed  architecture  is  the  way  to  go. 


S  .  h;  - 
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with  all  its  comol exotics . 


The  key  point  that  we  are  making  is  that,  nowhere  in  these 
particular  minutes,  or  any  of  the  ;  •-•a.-  :iue  meetings ,  wo 
see  any  indication  that  somebody  has  done  a  study  of  as  simple 
an  issue  as,  for  instance,  who t  would  be  the  potential  TDCC 
throughput  improvement  resulting  from  the  introduction  of  a 
cache  memory .  rho  wav  we  n  ek  at  -  . ,  a  ;  Kips  e,,~oi:-or 
is  taking  on  the  average  5  microseconds  per  instruction, 
inis  would  correspond  t  3  a  memory  cycle  somewhere  between 
500  nsec  and.  i  usee  with  a  cache  memory  is  completely 
possible  to  get  down  :o  "0/1 ha  nano-sere nds .  Plenty  of  studies 
in  the  computer  Industry  have  shown  that  one  does  not  have 
to  have  a  very  large  -ache  sine  to  g  't  to  hit  ratios  of  the 
order  of  901.  Such  a  modification  would  be  totally  software 
invisible,  and  even  from  a  hardware  engineering  point-of -view , 
is  not  a  big  deal.  In  fact,  it  has  been  done  a  number  of  times 
by  many  many  manufacturers  who  hu-c  rejuvenated  old  designs 
that  way.  The  point  is  that  this  is,  comparatively  speaking, 
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-i  much  easier  thine  to  do  instead  of  ail  of  these  complicated 
analyses  on  arcniteetui ai  possibilities .  The  fact  that  it 
has  not  been  done,  or  at  least  nor  documented,  removes  a  lot 
of  credibility  from  the  studies  that  arc  being  presented 
in  these  minus's. 

The  minutes  ina'cate  that  the  durst  Height  Compensator  (BHC, 
i'mart  fuse)  will  not  significantly  increase  the  Fire  Control 
trajectory  processing  throuchput .  So  this  is  additional 
s\  ider.ee  that  many  of  the  no*.-/  rcauxrouients  of  Tridont  II 
do  nor  contribute  .in  any  sacnif leant  way  to  the  throughput 
issue,  and  iiFC-  remains  the  crucial  question. 

rhe  bulk  of  the  a-.ir.ut as  are  dedicated  tc  a  discussio:.  of  the 
correlation  met hoc.  rhe  method  is  assort  tally  based  on  the 
idea  that  she  gravity  field  variation  effects  over  the 
trajectory  corr*  Lata*  very  strongly  with  the  gravity  field 
anomaly  at  the  point  o"  in  inch.  Tais  m.-chod  had  bean 
previously  consiciorec. ,  however ,  what  has  been  presented 
at  this  meeting  is  a  r.cw  implor.iantntioa  cal  led  the  He  lease 
Me  thou  which  is  ahov.n  to  have  the  ability  to  achieve  an 
accuracy  of  double  that  or  the  C4.  The  most  promising 
aspect  of  this  method  is  that  only  a  limited  number  of 
co-cf f icients  (21)  must  be  computed.  Vhc  claim  is  also 
made  that  this  method  roqui -os,  in  terms  of  processing 
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c opacity  (storage  and  Kips)  ,  about  the  same  as  that  required 
by  the  computation  of  no  more  than  24  Stokes  vectors,  that  is 
an  order:  of  magn !  tude  reduction.  The  24  vectors  in  question 
correspond  '  o  one  initial  vector  (at  launch  point)  per  missile 
Thus,  this  is,  potentially,  a  dramatic  saving  from  the 
implementation  method.;  using  a  airline  approximation  which 
require  14  vectors  per  missile  as  oppose.’  to  the  J  00 
vectors  that  were  thought  to  be  needed  to  begin  with.  (Sec 
November  1C,  197'  minutes. ) 

Another  key  point  chat  comes  out  of  the  documentation  is 
that  although  this  Release  method  appears  very  promising 
i.r  ’'•educing  tr  ■  "oquir  d  throughput ,  it  requires  extensive 
va  1  i dacron,  which  is  ires  ntly  underway ,  before  it  can  be 

C ".TTi  1  L  L:  . 
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to  compute  a  4  to  5  point  spline  fit,  which  would  throw  one 
bacK  to  the  kinds  of  throughputs  that  we  have  seen  mentioned 
:.r.  the  Section  8.1,  8.2,  and  8.3  above . 

tin.-  minutes  also  mention  the  interesting  point  that  no 
v.  .;(•  ;.r.v. tea  of  execution  time,  or  memory  requirements,  have 
be-  •••>  developed  for  the  various  possibilities  for  improving 
tiie  eon t r ibu t ions  to  the  W-Matrix  errors.  This  is  interest¬ 
ing:  mostly  h  a  the  point-of-view  that  by  the  time  this 

mo  -i  i:v.j  mot,  wo  are  about  two  years  down  the  road  from  the 
meeting  tho.t  was  discussed  in  Section  8.1. 

The  basic  cone i us ions  of  the  meetings  seem  to  be  as  follows: 

Accuracy  equal  .724  Release  Method 
Accuracy  equal  . 524  Release  Method 
Ac .  irncy  equal  .324  stokes  Method  (4/5  spline' 

;'o:eo  lii-’G  computation  during  the  transition  phase 
."wh,  -  ihen  the  firing  phase,  while  improving  the 
t  iv  ouohput ,  raises  some  concerns  because  the  data 
would  not  be  recent  (data  staieness  issue).  A  study 
of  the  effects  of  data  staieness  is  called  for  by 
the  minutes. 

Ho  requirements  have  been  identified  anywhere  that 
would  suggest  that  memory  in  excess  of  262  ki lowords 
might  be  required  by  the  projected  applications . 


<;.  s.  Ik,-. 
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V.iew  Graph  A- 2  9  makes  a  further  pitch  tor  the  approach  of 
using  micro-processors  as  opposed  to  tno  budget  assumption, 
which  is  augmen t  throughput  by  additional  Basic  Processors. 
The  arguments  given  against  the  use  of  additional  Basic 
Prc censors  are  the  f  t  lov/in- 1 : 


-  MCC  Spa  -c 

Poor  Hardware  Cost  Effectiveness  Dollars/Kips 

Limited  Throughput  Growth  Increment 

Both  of  these  approaches  seem  to  us  to  b a  poor  ones  and 
so  we  are  somewhat  surprised  in  seeing  this  particular 
view  graph  and  this  particular  comparison.  The  fundamental 
comparisons  that  should  be  made  is  between  a,  so  called, 
distributed  architecture,  and  software  transparent 
redesign  of  the  TDCG  using  state-of-the-art  technology. 


S.  h:<\ 


-1 19- 


Con  tract  # N0001 4-8 0-C- 0104 
CURL  #A005 


3  .  "  October  1  .1. ,  19  79  _>lomor}_  S Rudy  _ 

This  ':rvr  vac  pioducou  by  Hughes  Aircraft  Corporation  and 
up;  l > '  jo  an  mrormal/ white  paper  examining  a  number  of 

a  L  tern..*  fiver  to  expand  the  addressability  of  tiie  memory 
con ‘•roller  beyond  the  current  256  kiiowords .  The  key 
aspects  of  thin  study  art  that  the  redesign  of  the  memory 
cent  r-  .Lie  r  ir  s  been  authorized  anti  committed ,  however, 
aiuiei  a  rtron  i  directive  that  no  other  system  components 
K.vo  to  bo  mod'  tied.  Furthermore ,  the  memory  control 
he  ire;  ve  las  i  crued  .or  one  megaword  addressability. 

•turns  seem  to  bo  underway  to  develop  an  actual  physical 
:unu:ry  .> f  512  k  1  ’  owerds ,  using  a  o4  K-bit  chip. 

..tie  .;o  the  characteristic  of  the  chip  being  utilized, 

:;ke  acc  ss  time  is  being  reduced  from  7  ticls  to  2  ticks 
r  ha  t  .  .i  down  to  5 2 0  nanc— seconds .  It  is  further  reported 
tha  •  the  redaction  of  the  access  to  520  »ano- seconds  will 
improve  the  M-nix  throughput  of  the  processor  by  30%.  We 
mr.,  frankly  surprised,  by  the  rather  modest 
level  of  throughout  improvement  resulting  from  a  3b  fold 
reduction  of  tno  access  time  to  the  memory.  This  must  be 
one  to  the  stand  constraint  of  confining  changes  only  to  the 
memory  cor,  t-.ro  11  <  >  ,  thus  th  »  Chi’  cannot  take  full  advantage 
of  ;:he  increased  ice  ; 's  speed  of  th  .  memory. 

The  paper  presents  a  n umber  of  possible  schemes  tor  increasing 
address  inn .  W<-  will  briefly  summarize  all  the  schemes 
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p,. osonti  d  and  their  evaluation. 

>o.' jh  ::  extension 

'■•!  La  :k-!v:,iO  consists  in  widening  all  of  the  controller  paths 
f rota  l.o  b ‘  Ls  (256  X -words)  to  20  bits  (1  megawords).  This 
Uv  he:  .o  del ini  cely  violates  the  directive,  namely,  to  modify 
C"'i\  the  MCCbU.  dor  this  reason  the  scheme  is  considered 
only  to  a-.. sc  extent.  The  study  indicates  that  this  scheme 
u:  cnnracf orix  >d  by  the  following: 

it  s  the  most  attractive  of  ail  the  schemes 
nr. tented. 

Tt  has  a  straightforward  implementation . 

The  hard warc/sof twa ro  architecture  of  the  system 
will  rem.ai  •.  the  same. 

The  basic  oroblc m  is  that  all  32  bits  of  the  word  have  been 
used .  Consequently ,  to  implement  this  scheme  a  redefinition 
of  the  instruction  format  muse  be  done  with  impact  on  the 
software,  of  course.  Wo  also  happen  to  agree  with  MAC  that 
this  is  the  best  scheme  and  we  know,  through  several  similar 
experiences,  that  the  software  impact  of  these  kinds  of 
redefinitions  does  not  necessarily  need  to  be  catastrophic. 
That  is,  the  key  is  the  proper  uefinition  of  the  new 
instruction  format  Sometimes  it  is  possible  to  define 
a  revised  i ns cruet  ion  format  so  that  the  impact  on 
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uoftware  can  be  contained. 

As  \:c  -,eo  it,  the  first  thing  to  do  would  bo  to  remove 
the  restriction  to  confine  the  modifications  only  to  the 
MCCi.R.  Tiiis  restriction  has  to  be  removed  in  any  event, 

L  -'ca.usa  with  such  n  restriction  it  becomes  essentially 
in.  visible  to  get  any  expansion  of  addressing  that  has 
any  true  architectural  and  application  value.  Once 
-.ho  restriction  is  removed,  it  would  be  important  to 
commission  a  study  for  a  redefinition  of  a  super-sc  t 
architecture  that  would  be,  to  the  maximum  extent 
I  ossicle,  compatible  with  the  present  TDCC  instruction 
format,  while  gaining  the  two  extra  bits  of  addressability 
in  the  instruction  format.  Only  if  such  a  study  would 
shov;  that  there  is  no  possibility  of  doing  this,  this 
particular  alternative  should  be  dropped. 

Au t  vmu fc ic  Memory  Purr li on tion 

This  schema  v/ould  envision  two  banks  of  memory,  256  kilowords 
each,  whore  automatically  every  store  would  be  doubled  in  both 
banks.  The  scheme  ends  up  using  the  full  512  kilowords 
of  memory  and  it  does  not  have  any  addressing  problem . 

However,  it  does  not  extract  any  usefulness  out  of  the 
extra  256  kilowords  other  than  extra  redundancy  and, 
consequently,  reliability.  What  is  wrong  with  using 
redundancy  this  way  is  that  not  all  the  program  and  data 
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str natures  in  the  system  need  full  redundancy.  Thus,  it 
is  a  rseuao  argument,  and  a  specious  one  to  argue  that  one 
would  yen  some  benefit  out  of  512  kilowords  of  memory  by 
this  kird  of  scheme,  since  the  same  reliability  effects 
can  be  obtained,  probably,  by  duplicating  only  about  lO'-i 
of  the  involved  information  structures  and,  consequently, 
not  west  Lay  all  kinds  of  memory. 

Main  Memory  Banking 

This  scheme  logically  widens  the  18  bit  address  to  20  bits 
by  concatenating  two  bank  r.elect  bits  (25G  kilowords  banks). 

The  bits  to  be  concatenated  would  be  provided  by  Bank 
Select  Registers  (BSP.)  .  The  idea  would  be  to  provide  one 
bull  for  each  HCCI.R  interface  i .  o .  ,  4  BSRs. 

This  scheme,  again,  violates  the  directive  of  confining 
changes  only  to  the  MCCLR.  The  study  reports  the  following 
advantages  for  this  scheme : 

BSR’s  concept 

All  changes  are  limited  to  the  OS,  and  more  specifically 
to  the  monitor,  since  the  monitor  would  have  responsibility 
for  the  BSR  switching  and  the  memory  assignment  activities. 

No  impact  on  application  tasks  and  on  the  software 
factory  (the  collection  of  tools  for  developing 
software).  The  reason  for  this  is  that  the  banking 
activity  woulo  be  handled  strictly  at  run-time. 


.S’.  ( In.  . 
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0:i  cha  aocona  page  of  the  discussion  of  the  main  memory 
banking  scheme,  the  study  gives  under  Paragraphs  1.,  2., 

3.,  4...  and  5.  a  number  of  very  good  reasons  why  the 
directive  imposed  on  this  redesign  d  memory  system  is 
totally  u  r.  a  c  c  e  ">  t  a  b  1  e . 

'•  )vnan ic  Memory  Relocation  (JpKR) 

This  scheme  consists  in  adding  another  level  of  address 
translation  so  that  one  would  no  from  the  16  bit  program 
address  to  the  18  bit  absolute  address  (the  present 
scheme)  with  then  the  13  bit  absolute  address  being 
"c:1  in  the  second  stage  of  address  translation  to  produce 
a  20  bit  physical  address. 

This  particular  scheme  would  cause  the  physical  address  ^ 
space  to  be  divided  inco  64  16  kilowords  segments.  By 
the  way,  the  16  bit  address  is  referred  throughout  the 
TDCC  documentation  as  being  a  virtual  address.  Actually, 
it  would  be  preferable  to  _efer  to  it  as  being  a  name  space 
address  as  opposed  to  virtual.  In  fact,  virtual  memory  has 
acquired,  in  practice,  the  connotation  that  the  program  name 
space  is  greater  chan  physical  memory  and  in  this  case,  we 
have  exactly  the  reverse.  Both  for  the  current  TDCC,  as 
well  as,  the  TDCC  with  the  DMR,  the  program  name  space 
is  considerably  smaller  than  the  physical  memory. 
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A  scheme  where  the  program  name  space  is  smaller  than  physical 
memory  is  well  justified  in  real-time  applications  where  one 
would  like  to  nave  a  number  of  program  name  spaces  stored 
directly  in  real  memory  so  that  they  can  be  commuted 
for  execution  at  a  very  fast  rate. 

Returning  to  DMR ,  the  paper  states  that  the  introduction 
of  the  extra  address  translation  stage  will  increase  the 
access  time  by  one  tick  and  namely,  it  will  bring  the 
access  time  to  780  nano -seconds  resulting  / n  an  N-mix 
throughput  improvement  of  only  24':  as  opposed  to  the  30% 
with  two  ticks.  frankly,  if  the  loss  _s  only  0.  of  the 
throughput,  we  would  not  consider  this  a  fundamental 
agrument  against  this  particular  sc. tome . 


Since  in  implementing  this  scheme,  one  would  have  to  utilize 
RS.’.s,  fr.c  same  as  laments  that  were  givtn  for  the  main  memory 
barking  apply,  namely,  that  as  long  as  one  is  under  the 
restriction  to  confine  the  changes  to  just  the  MCCLR  then 
this  scheme  will  not  work. 

Appending  Tib  and  MID 

TID  stands  for  Task  Identification  Numbep  and  HID  for  Module 
Identification  Number.  The  idea  of  this  scheme  is  again  to  use 
the  same  RSI’s  that  would  bo  used  in  the  DMR  scheme,  but  append 
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w w o  bycas,  one  to  contain  the  TID,  and  the  other  to  contain 
the  MID.  Ail  this  would  do  is  add  some  additional  protection 
capability.  it  can  be  validly  argued  that  such  protection 
oepabii  i-ties  would  be  redundant  with  what  already  exists  in 
tnc  computer  anyway.  The  paper,  therefore,  recommends  that 
jhis  particular  scheme  be  dismissed.  We  totally  concur  with 
i  t . 


The  final  cone1 us ion  or  the  paper  is  that  the  only  scheme 
bunt  is  consistent  with  the  directives  to  confine  changes 
to  MCCLR  is  the  memory  duplication.  The  paper  itself  winds 
up  r<  commending  the  DMR  scheme.  We,  believe,  that  first 
of  all,  the  restriction  should  not.  have  been  imposed  in  the 
first  place,  and  secondly,  that  actually  one  should  consider 
mare  carefully,  the  register  extension  scheme.  In  particular, 
with  cue  idea  of  coupling  it  with  the  widening  of  the  address 
space  of  the  individual  user  task  since  the  obvious  trend  is 
,:or  user  processes  to  use  very  large  name  spaces  especially 
lor  the  handling  of  data. 
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o.o  J one  10/1 l,  1 9 S 0  Dahlgren  Program  Review 

Ac  the  program  review  held  in  Dahlgren  on  Juno  10/11,  1980, 
Mr.  Car  l  ton  t  ake  indicated  that  the  whole  issue  of  the  future 
do.  si an  of  the  ICS  system  has  lost  most  of  its  criticality 
be  cause  oi  some  major  program  changes  that  have  occurred 
since  the  CJC  present  effort  was  started.  Basically,  as 
wo  ;:r  dees  tana  it  iron:  other  sources,  the  major  program 
hangas  c;r<.  that  the:  Trident  II  program  has  been 
discontinued  and  replaced  by  a  more  modest  program  of 
up-grade  of  the  ■'!  (C-1U)  . 

Mr.  Duke  indicated  chat  the  throe  major  improvement  areas 
high  Frequency  Gravity  Compensation,  W-Matrix,  and  at  Sea 
calibration  arc  presently  considered  part  of  the  moderniza¬ 
tion  program.  Such  a  program  will  have  its  initial  flight 
tests  in  the  36/87  time  frame.  Mr.  Duke  further  added  that 
the  project  intentions  is  to  study  all  of  these  different 
computational  problems  for  the  next  two  or  three  years 
so  that  more  precise  ideas  would  be  jelled  on  how  to  handle 
them.  This  extended  engineering  phase,  of  the  next  two  to 
throe  years,  should,  then  result  into  a  much  more  precise 
information  on  whether  the  FCS  needs  more  CPU  power.  Mass 
Storage,  etc.,  etc.. 

Mr.  Duke  confirmed  that  the  HFG  is,  indeed,  the  big  item 
and,  furthermore,  there  is  a  commitment  to  have  at  least 


a  baseline  scheme  for  handling  it  by  the  end  of  1931. 
Apparently  the  project  has  made  a  committment  to  actually 
implement  various  HFG  algorithms  on  the  present  machines 
(both,  the  CDC  6700  and  the  BP)  .  These  experimental 
.imp -omenta  tie  ns  would  be  aimed  at  finding  out  the  answers 
to  questions  such: 

How  much  additional  compute  power  is  required. 

bow  much  additional  memory. 

how  ..inch  additional  mass  memory  etc. 

hr.  make  also  indicated  that  the  new  MK/6  inertial  guidance 
system  is  very  different  from  the  past  one  and  it  may 
include  on/line  calibration  (at  sea  calibration) . 
no  also  stated  that  it  is  the  view  of  the  project  that 
the  new  guidance  system  could  pose  a  great  burden  on  the 
f  xi sting  computing  hardware  and  this  is  one  of  the  primary 
reasons  why  micro  processors  are  being  considered.  No 
decisions  have  yet  been  made  with  regard  to: 

Does  the  accuracy  gain  justify  the  added 
complexity,  risk,  etc. 

If  the  accuracy  gain  justifies  the  new  approach 
will  it  be  done  by  Guidance  or  Fire  Control? 
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Bosidos  convoying  an  impression  of  lack  of  urgency,  because 
ox.  the  programmatic  changes  (Cancellation  of  Trident  II  Program), 
-•it:.  Duke  also  gave  us  a  very  strong  impression  that  the  entire 
issue  of  iii’G  was.  no  longer  to  be  considered  as  important  as 
.u  ha a  1;  on  in  the  past.  The  importance  of  I1FG  has  been 
extensively  eleex’aontod  in  this  section  in  the  process  of 
rov.i  owing  the  minutes  of  the  working  group  on  throuohput .  It 
rests  on  tiie  fact  that,  just  about  any  approach  to  I-IFG  computation 
seems  to  lead  to  a  requirement  for  a  computer  with  many  times 
t ho  power  of  the  TDCC,  at  least  in  terms  of  Kips. 

The  way  Mr.  Duke  justified  this  much  more  relaxed  attitude 
on  hi 3  part,  during  our  program  review,  was  that  the  early 
.studios  were  based  on  the  viewpoints  of  theoretical  geophysicists 
which  while  being  correct,  were  excessively  coi:.pl ex  and  cumbersome 
since  then,,  according  co  him,  the  approach  has  been  simplified 
considerably  cutting  down,  consequently ,  on  the  amount  of 
computation  that  is  to  be  performed. 

We  specifically  asked  Mr.  Duke  to  give  us  some  examples  of 
this  type  of  simplification  and  he  indicated  that,  for  instance, 
considerable  simplification  comes  from  realizing  that  most 
of  the  nigh  Frequency  Gravity  effect  occurs  during  the  boost 
phase  of  the  trajectory.  Another  simplification  came 
from  realizing  that  instead  of  computing  a  Stokes  double 
integral  every  second,  one  could  very  easily  cut  it  down 
co  computing  a  Stokes  integral  every  10  seconds  and  then 
interpolat  ir.g  the  gravity  vectors  every  one  second.  Since 
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t'ne  boost  phase  is  approximately  2  00  seconds,  this  reduces 
the  number  of  gravity  vectors  that  have  to  be  computed 
(Stokes  integrals)  to  20  or  so.  lie  also  referred  to  the 
five  spline  interpolation  method,  which  will  result  in 
about  the  same  accuracy,  but  will  result  into  an  order  of 
magnitude  reduction  of  computation.  Finally,  he  referred 
to  a  method  which  allows  computing  a  single  gravity  vector 
at  the  launch  point.  lie  indicated  that  this  yields 
approxima toly  about  60'.'  of  the  accuracy  of  the  five 
spline  method  mentioned  above.  Mr.  Duke  must  have  been 
referring  to  the  Release  method  that  was  discussed  in  the 
last  of  the  work ing  group  meeting  reports  that  we  have. 

he  also  indicated  that  on  top  of  all  these  simplifications 
one  can  simplify  the  actual  Stokes  method  (upward  continuation) 
resulting  in  a  greatly  simplified  computation  of  the  individual 
gravity  vectors.  Finally,  he  stated  another  approach  is  to 
precompute  the  gravity  vector  at  several  points  in  the  soar 
around  the  earth,  and  use  lots  of  mass  memory  to  store  these 
precomputed  numbers,  to  get,  consequently,  a  very  fast 
throughout . 

After  our  careful  study  of  the  minutes  of  the  working  group 
or.  throughput,  we  believe  that  all  of  the  above  alleged 
simplifications  have  been  discussed  extensively  by  that 
working  group  and  that  the  only  alternative  that  was 
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not  presented  at  those  meeting's  was  the  notion  of  precomputing 
tie  gravity  vectors  and,  consequently,  trading  off  storage 
against  computational  power.  So  except  for  this  alternative, 
we  do  not  see  that  any  of  the  information  given  to  us 
at  Dahlgren  changes  any  of  the  conclusions  that  we  reach, 
as  far  as  computing  system  architecture  is  concerned,  from 
the  study  of  the  documentation  available  to  us. 

We  believe,  in  particular,  that  it  is  most  unfortunate  that 
none  of  the  documentation  made  available  to  us,  gives  us 
any  information  whatever  on  the  potential  trade -off  between 
tile  use  of  mass  storage  memory  (resort  to  precomputation 
f  the  gravity  vectors)  versus  greater  computational  power . 

In  fact,  as  we  stated  several  times  before,  our  overall 
reaction  to  the  throughput  studies  is  that  the  computational 
algorithms  for  HFG  are  making  an  excessive  demand  for 
computing  power.  What  wc  are  saying  is  that  from,  our 
experience  of  having  designed  many  computing  systems, 
those  requirements  were  coming  across  ns  too  lopsided 
in  the  direction  of  computer  power.  Consequently,  it  would 
have  been  very  interesting  for  us  to  look  at  alternatives 
whore  storage  could  have  been  traded-off  against  computing 
pov/e  r . 


(».  .S'.  ] nr. 


-131- 


Contract  #NU0014-80-C-0104 
CDRL  #A005 


8 . 7  GSG  Cone J  usions 

In  this  section  we  will  briefly  describe  the  direction  GSG 
would  recommend  for  the  evolution  of  the  FCS.  The  evolution 
being  required  by  the  additional  and  expanded  applications 
that  have  been  documented  to  us.  Our  recommendations  are 
aimed  at  selecting  a  direction  of  technical  evolution  of 
the  FCS  computer  system  that  would  minimize  the  overfill 
technical  risks  of  the  project.  Technical  risks  are  equated 
by  us  with  risks  associated  primarily  with  the  development 
of  systems  software. 

The  most  important  conclusion  we  can  arrive  at,  after  the 
review  of  the  documentation  regarding  additional  application 
requirements  is  that  the  High  Frequency  Gravity  compensation 
represents  the  predominant  factor  in  the  documented  workload 
for  the  modernization  program.  An  ancillary  conclusion  is 
that  the  most  important  factor  in  determining  the  computing 
workload  generated  by  HFG  is  the  selection  of  the  HFG  algorithm. 
In  light  of  the  above,  we  offer  the  following  recommendation: 

Recommendation  #1: 

Every  effort  possible  should  be  performed  to  formulate 
an  algorithm  that,  while  consistent  with  the  accuracy 
requirements,  imposes  the  very  minimum  computational 
load  on  the  Basic  Processor. 
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In  other  words,  what  we  are  saying  is  that  efforts  spent 
on  the  algorithm  will  pay  a  handsome  dividend  with  regard 
to  insuring  a  non-lopsided  architecture  for  the  computing 
system. 


The  evidence  provided  to  us  points  in  a  clear  and  convincing 
way  to  the  fact  that,  regardless  of  what  algorithm  is  ultimately 
chosen  for  HFG ,  a  processor  of  considerable  greater  power  than 
the  present  Basic  Processor  is  required  by  the  program.  We 
would  also  conclude  from  the  evidence,  that  the  new  processor 
would  have  to  have  a  throughput  capability  of  at  least  1  HIP. 

Our  review  of  -.ne  architecture  of  the  TDCC  and  of  che  Operating 
System  RTOS  shows  tnat.  a  solution  based  on  a  processor  with  an 
architecture  that  is  upward  compatible  from  that  of  the  present 
TDCC  should  not  have  unacceptable  disadvantages. 

Our  view  of  upward  compatibility  implies  the  careful  examination 
of  the  possibility  of  modifying  the  instruction  format  so  to 
allow  increasing  the  process  addressability  to  at  least  18  bits 
(256  kilowords)  as  opposed  to  the  present  16  bits  (64  kilowords) 
We  realize  that  improving  addressability  by  2  bits  requires’ 
reformatting  the  instruction  format  to  obtain  the  extra  bits. 

We  believe,  however,  that  this  is  very  important,  in  view  of 
the  overall  trend  for  user  or  application  programs  to  use, 
cxpecially  for  their  data,  segments  greater  than  64  kilowords. 
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In  light  of  the  above  comments,  we  would  like  to  make  the 
following  recommendations: 

Recommendation  ff2: 

Commission  the  design  of  a  32  bit,  high  speed, 
scientific  processor  of  at  least  1  MIP.  Such 

( * ) 

a  processor  should  be  strictly  upward  compatible 
with  the  TDCC ,  and  it  should  have  a  segment  size 
of  at  least  256  kilowords  (18  bit  application 
program  addressability,  or  18  bit  virtual  addresses) . 
Such  a  study  should  result  in  a  design  that  is 
sufficiently  complete  to  determine  such  factors 
as:  Cost,  volume,  implementation  time,  power 

consumption,  reliability,  etc.. 

Recommendation  # 3 : 

Do  not  consider  distributed  architectures  until 
either  the  study  referred  in  Recommendation  #2 
results  into  a  very  strongly  negative  indication 
(wc  do  not  expect  that  such  a  negative  indication 
will  result  from  the  study),  or  requirements, 
other  than  those  stated  in  the  documentation 
reviewed  by  us,  give  a  very  strong  indication 
that  a  multiprocessor  architecture  is  truly 
required . 

(*)  Strictly  upward  compatible:  allows  importing  any  TDCC 
software  via  a  simple  recompilation  process. 


i  S  (  t  ll'.r. 


We  believe  that,  if  the  definition  of  the  upward  compatible 
. .rchitecture  of  the  new  processor  is  carefully  done,  the 
Monitor  and  the  execs,  which  are  written  in  assembly 
language,  will  transport  to  the  new  architecture  with 
essentially  no  problems.  In  any  event,  even  if  there 
were  to  be  problems  importing  the  Monitor  and  the  exec, 
we  expect  that,  if  the  architecture  is  truly  upward 
compatible,  the  modifications  that  would  be  required 
would  be  local  in  nature  and  greatly  aided  by  the 
axis  tine;  PDLs. 

Our  review  of  the  RTOS  design  leads  to  the  conclusion 
that,  even  though  there  are  some  features  of  that  design 
which  can  be  questioned,  in  balance  it  is  a  good  design, 
furthermore,  the  additional  application  requirements  that 
have  been  documented  to  us,  do  not  constitute  evidence 
that  the  present  architecture  of  RTOS  is  obsolete. 

This  is  an  important  reason  for  our  recommendation  that 
a  strong  effort  be  done  in  the  direction  of  enhancing  the 
FC3  System  via  an  upward  compatible  higher  power  processor. 


